28
Jul
2009
GeoWeb Standards – Your thoughts
Later this week I’m speaking at GeoWeb about the current progress of GeoWeb standards, how far we have to go, and how to get there. We have KML and GeoRSS leading the way in searchable, linkable formats, but still a plethora of Shapefiles strewn about. There are questions of findability, semantic ontologies, durability, and expressiveness. What are the adoption rate of these formats and their utility in the future real-time, mobile, linked, open web?
What else do you think is the good and bad of GeoWeb standards?
My name is
July 28th, 2009 at 1:18 pm (#)
GeoRSS, KML, and GeoJSON are the itching powder, squirting ink pen, and dribble cup of geodata formats. The only worse ones are all the others that have no hypertext capability at all (with apologies to Clay Shirky).
July 28th, 2009 at 1:28 pm (#)
Thanks Sean – excellent quote
I agree that these formats each have issues, yet are the most closely aligned with the Web, rather than a file just served off the web.
One particularly, potentially interesting format that’s being overlooked is OpenStreetMap. I’m impressed with the linkedgeodata.org and the 3 Billion triples.
Unfortunately we still have a ways to go both in providing useful, usable, expressive formats, and moving tools and data providers to using these formats.
July 28th, 2009 at 1:41 pm (#)
So, Sean loves GML? XML schema has anyURI as a primitive property type after all
GML has certainly its use, but it is not always the right tool (exchange format) for the right job.
There is definitely a ways to go, but the problem is that it is often not clear what would work well upfront, and even if you find something that works well in one case, it doesn’t work well in another case (if at all).
At least I don’t think the goal is to have one unifying format, but we’ll end up with multiple (smaller) formats instead, each which should do their specific job well. The internet and the Geoweb are no monoliths, so neither are the standards which drive them.
July 28th, 2009 at 1:49 pm (#)
I agree with ajturner on the .osm format – it is a breeze to code scripts for that format. And I do think that if you give JOSM a couple of years, you’ll get something that will be quite capable of standing against traditional desktop GIS software.
On the other hand, GML is too loosely defined to easily develop tools that work with *all* kinds of GML. And I get headaches every time I have to read an OGC standard to implement it. Any geo-standard that is longer than 5 pages deserves being thrown into the garbage bin.
July 28th, 2009 at 2:01 pm (#)
@IvanSanchez: It is definitely tough to develop a generic GML reader. The next file you try gives new problems. However, at least in all those pages of the GML spec, the authors try to add some order to the nearly endless flexibility of XML schema (which can be abused in many ways). Also additions like the Simple Features profile help, but even then it is difficult.
If you would ask me honest and personally, I think GML will still live on for a long time, but it will be mostly used for specific formats / application schemas, like CityGML, OS MasterMap, etc. It will never take the role shapefiles (still) have right now, because everyone will let his GML writer output a slightly different flavor, and dealing with all those cases is a too high barrier for most people (cost and time).
July 28th, 2009 at 3:57 pm (#)
From my perspective – GML is like programming in XML. The documentation reinforces that too as it’s primarily about classes, inheritance, including namespaces, etc. So writing a parser/reader is like writing a scripting interpreter.
So @Frank – I agree with your ending sentiment. There won’t be “one format to rule them all”, but instead what’s working is linking between formats. Consumers can choose if they want the HTML version for a human browser, or the KML for 3D browsing, or the GML/Shapefile/Spatialite for some GIS analysis.
thanks for the thoughts, and keep them coming! I’ll make sure and share the outcome presentation and feedback from GeoWeb.
July 28th, 2009 at 8:09 pm (#)
KML is fine, but fairly limited in what it can convey… still wishing that X3D had been better up to this task (I come from an OpenInventor background). GeoRSS drove me a bit crazy when trying to build some feeds for Google… the GeoRSS.org schema is not properly setup.
Frustrations documented in a couple days of posts ending with:
http://schwehr.org/blog/archives/2009-07.html#e2009-07-28T14_12_02.txt
So I’ve got feeds, but even though they validate, I don’t think they are right.
Now if I want to share properly documented topo or bathy, I have to dive into the world of Collada, BAGs (bathymetry attributed grids), opendap, etc or get lost in the land of proprietary file formats. For some of us how the data was processed and what the uncertainty values are is almost as important as the actually data.
July 30th, 2009 at 8:22 pm (#)
I rambled in my responses, so I posted my thoughts here:
http://tr.im/uPYC