Passing along to the Apache SIS community since I think this will be useful as well.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: George Percivall <[email protected]> Date: Wednesday, November 25, 2015 at 6:09 AM To: jpluser <[email protected]> Subject: Fwd: ACTION-98: Look at a list/matrix of the common formats (geojson, gml, rdf, json-ld) and what you can or can't achieve with it > > > >Chris, > > >I recall you were involved or leading an ESDSWG working group on GIS >vector formats. That group might find the table below of value. > > >George > > > > > >Begin forwarded message: > >From: >Clemens Portele <[email protected]> > >Date: >November 25, 2015 at 7:57:06 AM EST > >To: >SDW WG Public List <[email protected]> > >Subject: >ACTION-98: Look at a list/matrix of the common formats (geojson, gml, >rdf, json-ld) and what you can or can't achieve with it > > >Dear all, > >below is a first attempt at such a matrix for vector data only. > >Beside a review (I am not sure that everything is correct or adequate) >this would need >- additional explanations in text, >- more work to align the terminology with the rest of the BP to make it >understandable for the different target audiences, >- links to the specification for each format. > >But before we work on this, I think we should have a discussion whether >- this is what we were looking for in general, >- the list of aspects is complete, too much, or missing important aspects >(e.g. time support, closely coupled APIs / service interfaces, etc), >- the list of formats is ok or whether we need to remove / add some. > >I hope the table is still readable once it passes the W3C list software :) > > > > >GML >GML-SF0 >JSON-LD >GeoSPARQL (vocabulary)Schema.org <http://schema.org> >GeoJSON >KML >GeoPackage >Shapefile >GeoServices / Esri JSON >Mapbox Vector Tiles >Governing Body >OGC, ISO >OGC >W3C >OGC >Google, Microsoft, Yahoo, Yandex >Authors (now in IETF process) >OGC >OGC >Esri >Esri >Mapbox >Based on >XML >GML >JSON >RDF >HTML with RDFa, Microdata, JSON-LD >JSON >XML >SQLite, SF SQL >dBASE >JSON >Google protocol buffers >Requires authoring of a vocabulary/schema for my data (or use of existing >ones) >Yes (using XML Schema) >Yes (using XML Schema) >Yes (using >@context) >Yes (using RDF schema) >No, schema.org <http://schema.org/> specifies a vocabulary that should be >used >No >No >Implicitly (SQLite tables) >Implicitly (dBASE table) >No >No >Supports reuse of third party vocabularies for features and properties >Yes >Yes >Yes >Yes >Yes >No >No >No >No >No >No >Supports extensions (geometry types, metadata, etc.) >Yes >No >Yes >Yes >Yes >No (under discussion in IETF) >Yes (rarely used except by Google) >Yes >No >No >No >Supports non-simple property values >Yes >No >Yes >Yes >Yes >Yes (in practice: not used) >No >No >No >No >No >Supports multiple values per property >Yes >No >Yes >Yes >Yes >Yes (in practice: not used) >No >No >No >No >No >Supports multiple geometries per feature >Yes >Yes >n/a >Yes >Yes (but probably not in practice?) >No >Yes >No >No >No >No >Support for Coordinate Reference Systems >any >any >n/a >many >WGS84 latitude, longitude >WGS84 longitude, latitude with optional elevation >WGS84 longitude, latitude with optional elevation >many >many >many >WGS84 spherical mercator projection >Support for non-linear interpolations in curves >Yes >Yes (only arcs) >n/a >Yes (using GML) >No >No >No >Yes, in an extension >No >No >No >Support for non-planar interpolations in surfaces >Yes >No >n/a >Yes (using GML) >No >No >No >No >No >No >No >Support for solids (3D) >Yes >Yes >n/a >Yes (using GML) >No >No >No >No >No >No >No >Feature in a feature collection has URI (required for ★★★★) >Yes, via XML ID >Yes, via XML ID >Yes, via @id keyword >Yes >Yes, via HTML ID >No >Yes, via XML ID >No >No >No >No >Support for hyperlinks (required for ★★★★★) >Yes >Yes >Yes >Yes >Yes >No >No >No >No >No >No >Media type >application/gml+xml >application/gml+xml with profile parameter >application/ld+json >application/rdf+xml, application/ld+json, etc. >text/html >application/vnd.geo+json >application/vnd.google-earth.kml+xml, application/vnd.google-earth.kmz >- >- >- >- >Remarks >comprehensive and supporting many use cases, but requires strong XML >skills >simplified profile of GML >no support for spatial data, a GeoJSON-LD is under discussion >GeoSPARQL also specifies related extension functions for SPARQL; >other geospatial vocabularies exist, see ???schema.org ><http://schema.org/> markup is indexed by major search engines >supported by many mapping APIs >focussed on visualisation of and interaction with spatial data, typically >in Earth browsers liek Google Earth >used to support "native" access to geospatial data across all enterprise >and personal computing environments, including mobile devices >supported by >almost all GIS >mainly used via the GeoServices REST API >used for sharing geospatial data in tiles, mainly for display in maps > >Best regards, >Clemens > > > > > > > > > >
