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!
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.
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.
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.
Welcome to the Esri DC Development Center blog. We write about features of our work on big data analytics, open platforms, and open data, what is new and exciting in the Esri and community, and general industry thought leadership and discussions of geospatial data visualization and analysis.
Please explore what we're working on and let us know if you have any questions or ideas!