We have previously mentioned here our ongoing work in launching a public geodata warehouse, which will allow anyone to share their geodata with the world, and to use the data that exists in it on their own, whether it’s in GeoIQ or another application.

Without launching into a full blown rant on the various pros and cons of some of the options available for geodata exchange formats, I would like to direct your attention to the poll on the right side of the page (RSS readers, sorry, but you’ll have to load up the full page in your browser).

Please post any comments/questions/initiation of full-blown shout-fests as comments in this post, or, even better, in the GeoIQ Forums.

Read on for a brief description of the poll options available, as well as my quick take on them.  The outcome of this (admittedly very unscientific) poll and the feedback that it generates, if any, will probably play a big part in exactly what, and how much, of the relevant standards and technologies we support initially, so please, don’t hold back!

Technorati Tags: , ,



The options:

GML – Geographic Markup Language

This is the OGC’s big, bad open standard.  This, and it’s smaller cousin, which I’ll get to in a little bit, form the basis for a lot of the XML-based geographic markup formats floating around (including KML), at least when it comes to describing geometries.

That being said, GML is big and complex.  It can handle the representation of any geographic feature data that I can think of, and you get all the fringe benefits of using XML documents for data exchange.

KML – Keyhole Markup Language

Everyone reading this is probably familiar with KML.  Best known for its use in Google Earth, which was, as the name would imply, previously Keyhole before that company was acquired by Google.

The geometry markup specified by KML is essentially a dupe of the relevant portions of the GML 1.0 and 2.0 schema (GML 3 adds a different, and incompatible way of specifying some of the geometry coordinate data), although it is completely contained within the KML namespace, and is not included as an extension of those GML schemas.

The main thing KML brings to the table, besides the fact that it’s built into every version of Google Earth, and will be an integral part of the ArcGIS 9.2 product line, is markup specific to things like styling, placemarks, and the like.  Most of this ties directly in to Google Earth features, but it’s still useful in other applications, and is the sort of thing that would need to be defined in a application-specific GML schema.

There are also some rather nifty additions to KML 2.1, such as support for 3d models, incremental updates, and Regions, which are useful in the incremental or on demand processing of large data sets.

GML Simple Features Profile

In short, the GML Simple Features profile is simply a subset of the full GML spec, which is more suitable for describing, well… simple feature data.

Long story short, this is what you’d be building off of if you wanted to do something like include a polygon description in a standard way in your own XML document without having to order the full GML enchilada.

Other…

I guess this would be things like ESRI’s shapefile, MapInfo TAB, CSV files, punch cards, or whatever else you would happen to think makes a better “standard” way of exchanging geographic information, to the extent that such a thing is possible.

 

6 Responses to GeoData Format wars: GML vs KML vs ?

  1. mookie says:

    Ok so I haven’t read all 600 or so pages of the GML specification but…

    I think that the issue we’re dealing with stems from the fact that GML doesn’t actually compete with shapefiles, or KML. GML describes the geometries themselves while KML describes how to display them. Shapefiles describe, geometries and their attributes.

    We really need a standard XML replacement for shapefiles, and that isn’t what GML is. GML provides a standard way of including geographic data in your own schemas, nothing more. Therefore the comment “we support GML” is pretty much meaningless.

    ogr and topp brands of gml look something like this:

    … schema specific xml that includes a gml fragment …
    ( — for ogr:

    … gml fragment …
    attribute_value

    )

    this is also the same response you get from a wfs getFeature request.

    since it already exists and provides free and open software, id say embrace the ogr spec, and try and pressure ogc to include it as a standard way of transporting GIS data.

    ~mookie
    (btw I am an F1er as well, I dont actually enjoy reading OGC specs in my spare time)

  2. mookie says:

    It ate my xml so…

    … schema specific xml that includes a gml fragment …
    ( — for ogr:

    … gml fragment …
    attribute_value

    )

    ]]>

  3. mookie says:

    ok whatever here’s the site: http://ogr.maptools.org/

  4. Jeff says:

    Actually, we’ ve been working with the GML Simple Features profile for almost two years now and have found that it’s a pretty good replacement for many existing geodata formats.

    But we work with all the formats listed above, so I don’t have to choose ;)

    Regards,
    Jeff

    http://www.carbontools.com

  5. Ron Lake says:

    The idea that GML does not provide a means to express attributes is simply WRONG. GML provides a simple scheme for encoding a geographic object. The object is an element like say . The children of this element are the properties of the Road –

    3
    paved

    … the coordinates

    So GML does provide a perfectly complete, good and extensible replacement for Shapefiles and much more.

    GML geometry is no more complicated than that of KML, but of course has many more geometry types since it supports non-linear geometries like Bezier Curves and Geodesics, and 3D solids to boot. Same model in call cases though.

  6. Kathy Allen says:

    Major thanks for the post. Want more.