Page tree
Skip to end of metadata
Go to start of metadata

The problem of data integration can be looked at from several angles: technologies, workflows, standards, etc. Within the context of each viewing angle a diagram can be drawn at varying levels of detail focusing on any component of the data integration technology stack.

This "technology map" uses the data management/integration technology elements, servers, services, and data as grouping themes. It attempts to give an overview of the entire existing data integration technology stack. These items are intended to be top levels of organization for documentation developed by the TSWG and collaborators. These will each be a link to a sub-wiki space containing other pages and content about the items.

Collaboration Tools: Listing and evaluation of a number of things like wikis that are used to help geographically distributed groups of people have conversations and share ideas.

Examples of Integration: Information on the use of one or more of the technology components listed below within a single system. 

Technology Components: Some of the major building blocks that the TSWG sees as being useful for making data and services readily usable to scientists and the public in a networked environment.

Sub-pages discussing individual components are being added--if you know about one, please add to a pre-existing page or create a new one!

Servers

Services/
Transport Protocol

Standards

Software Packages

File 

Visualization 

Storage

Scripting

THREDDS Data Server

WMS

NetCDF  

Matlab

GeoServer  

ESRI REST?

CF Conventions

R

ArcGIS Server

Most OGC standards (WCS, WFS, etc)

RDBMS, File Geodatabase, shapefile

Python

Database

WCS

JDBC /SQL 

S+

GeoServer

OPeNDAP

Transport Encodings

GIS

ArcGIS Server

ESRI REST?

OGC-XML (O&M, WaterML, GWML, GMLSF, KML, SWE)

ArcGIS

MySQL (http:--www.mysql.com-)

Feature

OPeNDAP-Binary 

QGIS

Oracle

WFS

Enterprise Standard-XML

GRASS

PostGRES (http:--www.postgresql.org-)

SOS

JSON / GeoJSON

GDAL

SQLServer

ESRI Rest

 

Productivity

Server Applications

Processing

Code

Microsoft Office

ERDDAP

WPS

HTML5

Web Applications

Uploader

ESRI REST

 

OpenLayers

ESRI GeoPortal (Metadata Server)

MetaData Server

 

eXcat

GeoNetwork

CSW  

 

Metadata

GICat

ESRI Metadata

 

ncISO

Enterprise Systems

RSS/GeoRSS (http:--www.georss.org-Main_Page)

 

 


things to fit in:

Glossary

Server:
File Server:
Database Server:
Other Server:

Services:
Visualization Services:
Grid Services:
Feature Services:
Processing Services:

Data Standards:
Data Storage Standards:
Data Transport Encoding Standards:

1 Comment

  1. Unknown User (jagui@usgs.gov)

    great ideas. this is very challenging to organize.  because Confluence is label-based, then I think it's okay to have some duplication in the navigation structure, but we should try to minimize.  Here's a really REALLY rough cut based on the ideas above.  It's not super-well thought out, so I already see some issues...   Feel free to edit.  I didn't want to put it in the main page until it gets cleaned up.

    • Servers
      • Database & Storage
        • SQL
        • NoSQL
        • XML databases
        • NetCDF (here?)
      • Web Servers
      • Application Servers
      • GIS (duplicate)
        • ArcGIS
        • Geoserver
        • Mapserver
        • Mapguide Open Source
        • Spatial Data Infrastructure (SDI)
          • Catalog Applications
            • GeoNetwork
          •  
    • Network Protocols
      • WebDAV
      • SAMBA/SMB
      • LDAP
      • SOAP?
      • REST?  (this is more of a 'style' than a protocol)
    • Web Services
      • Visualization
      • Grid
      • Feature
      • Processing
      • Other
    • Programming/Scripting Languages
      • HTML5
      • Javascript
        • Libraries
          • GIS
            • ArcGIS Javascript API
            • OpenLayers
            • Proj4JS
            • GeoExt
          • UI
            • Sencha (ExtJS)
            • jQuery
            • YUI
            •  
      • Python
        • Libraries
      • Java
      • PHP
      • Perl
      • Ruby
      • R
      • S+
      • Matlab
      •  
    • Programming Libraries (children are duplicate)
      • GIS
        • GDAL
        • OGR
        • Shapely
      • Graphs Charts
      • PDF
    • GIS 
      • Desktop
        • ArcGIS
        • GRASS
        • QGIS
        • uDig
        • MapWindow
        • SAGA
      • Server (duplicate)
        • ...
      • Spatial Data Infrastructures (SDI)
        • ESRI Geoportal Server
        • OpenGeoportal
        • OpenGeo GeoNode
      • Catalog Applications (should move under SDI?)
        • OSGeo GeoNetwork
        • Gi-Cat?
        •  
      • Web Services
        • WMS
        • WFS
        • WCS
        • WPS
        • SOS
    • Data
      • Transport (Interchange) Standards
        • GML
        • KML
        • WaterML
        • GWML
        • GMLSF
        • JSON
        • GeoJSON
    • Online Apps - SAAS?
      • Google Apps (Google Docs, Sites, Fusion Tables)
      • Yahoo Pipes
      • TitanPad
      • [this is multi-category stuff]
    • Productivity
      • Microsoft Office
      • Online Apps...
        • Open Office
        • Google Docs
        • eSharepoint
        • Office 365
        • Confluence

    My thinking is if we set this up as a test structure and configured each node to automatically load content with the applicable labels, then the structure would be dynamic.   Maybe we need a "Master Docs" directory node where folks can create content and label it accordingly so it gets picked up by this dynamic structure?  For actual leaf nodes, we don't need to statically include each child I listed above... e.g., we don't need to include ArcGIS, GRASS, QGIS, uDig,... under GIS->Desktop...   as long as content is labeled "GIS desktop", then it will automatically appear under this node.
    Farial's been experimenting with this stuff in Confluence, so I think she can configure this to work.  Maybe just start with one sub-node first to make sure it works the way we think.