Takeaways from OpenGeo’s Comments on OGC and the Proposed GeoPackage Specification
When a dense document related to geospatial technology gets retweeted enough times, by enough smart people, I take notice. And, I also wonder how many people will "take a pass" on reading that dense document. That happened today. Several tweets in my feed pointed me to a document on the OGC discussion list "requests" titled GeoPackage comments from OpenGeo. In it OpenGeo's Chris Holmes shares his response to a call for comments from OGC (press release) about the candidate GeoPackage specification (download Word doc) and mixes it with concerns about OGC specs and the OGC process. It's worth reading in full, but I want to summarize some of Holmes' key points that I think provide a valuable "state of the art" observation of how standards of various kinds are made these days.
1) Suggested changes to OGC specs and its spec process
There are two main things to change. The first is easier, which is just making the specifications more accessible and relevant, easier to implement a valuable core. The second will be more challenging, and will likely require some deep shifts in how the OGC approaches creation of standards.
I understand the second suggest to refer to integrating some of the processes and collaboration techniques used in open source software.
2) OGC specs (including the GeoPackage candidate) are not accessible, relevant, easy to implement, nor a valuable core. Holmes compares the MapBox mbtiles tiles spec to the the GeoPacakge Spec, prompted by comments from Justin Deoliveira. Deoliveira noted:
Yup. Reading this makes me feel warm and fuzzy inside:http://mapbox.com/developers/mbtiles/
While reading the geopackage spec makes me want to run for the hills.
Holmes explains why he feels Deoliveira feels that way in
five six points:
- The former is an immediately readable URL, the latter a Word document.
- The former has no boiler plate, it just jumps in, while the latter has pages of text to scroll past to get to the point.
- The former has no marketing promise nor does it discuss the spec's future as a standard and tells of the single problem it will solve, while the latter includes such marketing topics and tries to solve many problems.
- The former takes three pages to explain how to implement the spec while the latter includes far more detail (in 97 pages).
- The former is modular (can stand on its own), while the latter depends on many other specifications.
- The former is easy to contribute to (via commonly used open source platforms and processes), while the latter has a very formal process.
3) GeoPackage spec has lots of potential in individual areas, but it's too big to be immediately implementable useful.
I believe it should be split up in to 5 succinct specifications, that only contain the core conformance classes. Additional extensions / non-core conformance ideas should be in extended specifications. ...The five specifications would be vectors, tiles, rasters, metadata and manifest.