[Requests] GeoPackage comments from OpenGeo

Pat Cappelaere pat at cappelaere.com
Fri Feb 8 11:20:48 EST 2013


+10
This was the longest email I have ever read to the end.
I really liked the suggestion to move to Github.  This is where it is done these days.  We could have to the spec and the implementation(s) and tests and comments in one place. 
I like geo-naive implementors as well (how different are they from neo-geographers?).  Focussing on that group is the right thing to do.  OGC specs have gone to some really bad extreme.  
Thanks for voicing this out in a nice way :).
Pat 

On Feb 7, 2013, at 7:51 PM, Chris Holmes <cholmes at opengeo.org> wrote:

> PART A
> 
> 
> 1. Evaluator: Chris Holmes, cholmes at opengeo.org 
> 
> 2. Submission: OGC 12-128r1, GeoPackage
> 
> 
> 
> PART B
> 
> 
> 1. Requirement: General
> 
> 
> 2. Implementation Specification Section number: General
> 
> 
> 3. Criticality: Major
> 
> 
> 4. Comments/justifications for changes: 
> 
> First I must apologize for the huge amount of text I am going to shove in to this first comment. I wrote up most all my geopackage responses before looking at this response format, and I'm not sure how it fits in. But I will just leave the bulk of the general comments here, and then repeat section 'B' for the more focused comments.
> 
> So why all these comments? The new GeoPackage specification contains some ideas with the potential to be one of the best things to come out of the OGC in many years. And I'd really like to see it become a successful specification, reversing the trend of less and less clear, relevant, and implementable standards.
> 
> A bit of background - I've been peripherally involved in the OGC since 2002, primarily as an implementor of specifications. I did the first open source implementation of the WFS specification, and have guided OpenGeo through a number of OWS initiatives, including making GeoServer the reference implementation for WFS 1.0, 1.1 and WCS 1.1. My organization has never been able to afford to attend in person OGC meetings and have a big hand in influencing the specifications. But we have faithfully implemented the specifications as much as possible, and tried to give feedback to those we are connected with. But it seems challenging to have a voice without a major investment in time and money to make all telecons and in person meetings.
> 
> In the last five years our developers have become increasingly frustrated with OGC standards, as they have become harder and harder to implement, with less relevance to our users and customers. We now only implement the new OGC standards when a customer pays us to, as our investment is better spent on other improvements. We've grown increasingly frustrated with the results of the OGC process, and when we've tried to help we've found it costly and time consuming. The quality of OGC specifications has gone down in recent years, while our needs have been much better met by 'open source' style specifications like GeoJSON, TMS, MBTiles and more. We also have a far easier time contributing to those standards.
> 
> I've engaged OGC staff members on this, and one consistent message is that we need to get more involved, to push harder, to explain our viewpoint. This set of comments is my attempt at doing that. Though much of it may come across as negative keep in mind that it's an attempt to help, as I fully believe in open standards, and I think the OGC has done an amazing job of getting organizations around the world to speak standards and require them in their solutions. But there is a real threat to the OGC, which is that if the quality, approachability and implementability of specifications goes down too far then people will start finding alternatives to open standards. This has already been happening, as I constantly have to defend our continued implementation of OGC standards to a number of allies.
> 
> Much of what the OGC has done in recent years is to move to the edges, helping information communities standardize what they need to. Which is great, and makes sense. But there needs to be a strength in the geospatial core that all will use. The vector portion of the GeoPackage specification has amazing potential, to fill a major general hole in the geospatial world. A great, web-friendly widely accessible transfer format could fill a number of needs, and get quick adoption. It is one of the biggest opportunities for the OGC, which is why I am sounding in now, as I want to be sure it fulfills its potential with maximum adoption. The tile portion of the specification could also do quite well, meeting a real need. The third area with major potential for standardization is a CSS type successor to SLD, as there are a number of implementations that could do well to be standardized. But for the most part these opportunities are rare, when many people are searching for a standard solution.
> 
> * General comments of OGC specifications
> 
> Before I start in on specifics of comments and general strategies for GeoPackages I want to write a bit more broadly about where I'm coming from. In general the circles I spend most of my time in are very negative on OGC specifications. At first they were viewed as a necessary evil, but worth doing. In the last 2-3 years most people are questioning if they are even necessary, and many have been concluding that they are not, moving ahead with open source code complemented by lightweight specifications. This audience is more of 'the cool kids', the open source crowd, the younger developers. But it should be remembered that they will be the ones coding the future, and if they don't see the value in OGC standards then they just won't implement them.
> 
> Note that this doesn't mean they don't see the value in openness, they do, and indeed most of them insist in working in a totally open source way - code and standards. And they will create standards when they are needed. My ideal would be to combine their innovation with the amazing work the OGC has done in getting acceptance of standards at the highest levels of government and industry. 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 will focus primary on the first concern here, though parts of the second, the current culture around creation of specifications, will likely creep in.
> 
> The first concern is well articulated by Justin Deoliveira. He's probably spent more time implementing OGC software than all but a handful of developers in the world. He did most all of WFS 1.1 and 2.0 in GeoServer, built the only truly general purpose GML reader that I know of (able to parse the schemas on the fly and turn them in to a real feature model), worked extensively with WMS, WCS and WPS, and helped implement the core complex feature model. I asked him about the geopacakge spec, and he said:
> 
> '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.'
> 
> 
> I believe it's worth explaining why I believe he says this, as it's relatively easy to dismiss it for the wrong reasons. The same comments could just as easily be said about GeoJSON or TMS.
> 
> First, it's a web address that can be read right away. It doesn't require downloading a pdf or word document, or accepting some click through agreement. Web native developers prefer to read things directly on the web. It's a subtle thing, but even a pdf doesn't 'feel' write, it speaks to control, not openness. And firing up Word is annoying. It puts a higher barrier to entry, and will give pause to a developer deciding whether a spec is worth implementing and then looking to suck down information after deciding it is.
> 
> Second, there's no boilerplate. I don't have to scroll through 4 pages of title and table of contents to learn what it's about. And after those 4 pages there's more cruft with a preface, a forward, and an introduction, lists of contributors, past versions.
> 
> Third, it doesn't open like a marketing document telling me all the problems it will solve - that it will enlarge the market and become the standard. MBTiles opens with exactly what it does: 'MBTiles is a specification for storing tiled map data in SQLite databases for immediate usage and for transfer.' It doesn't try to convince me it will become _the_ standard, it just tells me what it does so I can decide for myself if it's useful. 
> 
> Fourth, it tells me the core information and no more. It's 3 pages, communicating to me that it can't be very hard to implement. GeoPackage actually should not be hard to implement if I've got Spatialite, but it took me half an hour of reading to realize that. A key thing here is that MBTiles provides links to what it builds upon. It doesn't replicate the TMS specification, it just links to it for people to read (this is where being on the web shines, as it doesn't require leaving word or acrobat to get more information). After the link it tells you how it's different, that it's constrained to web mercator. By contrast the geopackage vector section lists every single sql geometry operation. And then has a matrix telling me which of 4 other specifications implements it. One could fairly easily just say that it's based on 13249-3 and adds Add/Drop GeometryColumn operations (and perhaps takes some away?) The general point is that the specification should present the user with exactly the information they need to implement it, no more and no less.
> 
> Fifth, it's modular. It doesn't require UTFGrids. And it doesn't include them in the main document in some conformance class that may be optional. It is an add on that also stands alone, so it can live and die on its own merits. If it was in the main document then I'd be confused as to if I _had_ to implement it - it being an add on communicates to me that it's not part of the core. The GeoPackage document will dump large amounts of information (like trigger statements in sql), and then some sub-clause will let me know that it's optional. It doesn't respect the reader, it makes the reader pay super close attention to every single detail.
> 
> Another big issue is the perception of how easy it is to contribute. Even to comment during the RFC period takes filling out some precise template. Not that it's a big burden. But any modern software developer likely knows how to comment or contribute on github like the back of their hand. Just by having the spec on github people know that it's meant to be forked and adapted, innovated with. The infrastructure communicates that to developers, while the OGC infrastructure communicates that they have to go through some huge process to give their feedback - that it's an 'experts only' place, a hermetic club that can spend their time writing specifications.
> 
> Personally I've also always had no idea if my feedback has any effect in the OGC. There's no feedback looping letting me know that what I contributed was valuable, because it rarely emerges, and even more rarely in an identifiable way. I found out much later that some of what I've said in the past has been talked about a lot. But since I have no feedback loop there's little to continue to draw me. And joining the list to discuss it requires being a member, and most critical decisions get made on the phone, not the list. I can't easily see the discussion that lead to the spec. (Admittedly mbtiles isn't great in this regard, but all the historical changes are easily followed line by line. A much better example of open discussion is geojson - I can see all the decisions that lead to the implementation). I never feel like I could spend a bit of time and potentially contribute something valuable, I have to be all in on the specification process. With open source we have many developers who clearly have other concerns, but they're able to make valuable contributions without spending much time.
> 
> The one valid criticism that can be made on the mbtiles spec is that it doesn't cover all needs. It's too simple. I agree there is a good bit of truth to that, but I think it's a criticism that is used to overrule all other considerations. There's an attitude that if a spec doesn't cover every imaginable need than it's not worth it. Though this starts to get to the deeper cultural shifts needed - I'm trying here to limit discussion to the general accessibility of specs.
> 
> So what are the general lessons to be drawn from this comparison? The more superficial ones are to just publish specs that feel like web natives, that can be read online, that don't have lots of boiler plate, that get to the point. That have easy infrastructure for people to comment in the way want, to have conversations on blogs in iterative feedback loops. This is probably the easier part.
> 
> The deeper thing for me is the attention needed to understand the specifications. The GeoPackage spec counts an audience that is absolutely committed to implementing the standard. Who likely got assigned as part of their job to do it. Indeed the audience seems to be other specification writers, not developers who want to implement readers or writers for the standard.  The mbtiles spec communicates some concepts to help people solve their problems. A big part of that is that MBTiles solves exactly one problem. GeoPackage attempts to solve all problems. And it's more concerned with its conformance rules than it is with communicating what an implementor needs to know.
> 
> I hope the above comments are helpful for some general ideas on how to make the specification more 'implementable'. To increase the audience who may be interested in helping interoperability. Some will probably be hard for the OGC to implement. But the thing I believe will help the most is to involve actual implementors of production ready software before a specification goes to 1.0. At OpenGeo we've implemented a lot of specifications, likely as many as all but a couple organizations in the world. And we've found that in recent years there are even more 'ideas' added to the specifications that have no true production ready working code against them. Past the surface accessibility this is the thing that has become clear to us as implementors - there is less quality control at the core of the standards process. There are things that are not well thought out, that don't come from a variety of perspectives. And this is incredibly important for the core geospatial specifications. GeoPackage will be a much stronger specification if time is given for GDAL/OGR and GeoTools implementations, where the developers can feed back what to improve to make it easier to implement. And the side effect would be that 80% of all production deployed geospatial software would understand GeoPackages, as those two libraries are easily included in that number of systems.
> 
> 
> 1. Requirement: General
> 
> 
> 2. Implementation Specification Section number: General
> 
> 
> 3. Criticality: Major
> 
> 
> 4. Comments/justifications for changes:
> 
> So the major thing I'd like to address in this comment is the granularity of the GeoPackage specification. 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.
> 
> There was a line in the introduction (which comes after the forward and the preface) that hits on what is to me a big problem: 'An application that accesses a GPKG will make use of the GPKG capabilities it requires; few if any such applications will make use of all GPKG capabilities.'
> 
> I think this is actually just rude to any implementor. Even though an implementor, by the spec's own admission, is probably going only going to use a part of the spec, they are more or less forced to read and understand the whole spec. Because there might be something relevant to them. The specifications authors should work to communicate to implementors exactly what they need to know. I think there's improvements towards that which can be made in each of the major sections, but I'll go in to those individually.
> 
> I believe there are actually five potentially great specifications in there. I also believe they are of varying quality and real world relevance. By putting them in one single specification it brings down the overall quality, as some things will be more thought out and tested and somethings will be less so. If they are in separate specifications than each can evolve on its own. And each can also live and die in the market on its own. Maybe that way of doing metadata just doesn't work well. Then the metadata geopackage spec can be upgraded, without having to touch the others. Maybe people just don't end up storing metadata. Maybe they don't use the manifest. Keeping things independent lets things evolve more easily.
> 
> It also just makes for good architectural design practices, keeping things modular. The OGC has made a lot of effort to make specs modular. But in my opinion there is a large difference between having a core spec that one knows must be implemented and some optional specs that add to it versus a big long spec with some conformance table that I have to read to see what's optional or not. With a set of complementary specifications I can pick and choose the one most important to me, and later pick up the others when they become relevant.
> 
> By splitting up in to 5 and reducing some of the extraneous information the geopackage specification could get to 5 really nice mbtiles-like specifications. Implementors would be able to grok the main concepts in minutes and get started on implementing, likely taking little time to get an interoperable standards compliant implementation in their software. 
> 
> The five specifications would be vectors, tiles, rasters, metadata and manifest. I do like the idea of a manifest, but I don't feel it should be mandatory, at least not the full xml document. One should be able to implement one of the component pieces and just a snippet of manifest to help identify it properly. And each specification should contain _only_ the core conformance classes. The additional conformance classes should be in fully separate specifications, to fully and quickly communicate to implementors what they _must_ do and what is some useful ideas if they want to do more. 
> 
> Though I am a bit biased, as I have a bigger vector background, I believe a concise gpkg-vector spec with some improvements could be wildly successful. The market has been wanting this. I have some thoughts on how I believe it could be specified better, but I'll articulate those in its own section. But it should be able to stand alone, with implementors just reading that one small spec and starting to create and consume vector geodata.
> 
> And each of the other pieces could be quite valuable on their own, solving smaller use cases. Together they should describe a whole package that can be shipped in one sqlite database file. But an implementor shouldn't need to understand all the parts to just do what they want. Unless they are making one of the few applications that requires all of it. But they can build up to there with each specification.
> 
> 1. Requirement: General (? - I'm not sure what number I'm supposed to put here)
> 
> 
> 2. Implementation Specification Section number: 9
> 
> 
> 3. Criticality: Major
> 
> 
> 4. Comments/justifications for changes:
> 
> While I believe the vector portion of the geopackage specification has the most potential there are a number of core issues that need to be addressed. I believe the biggest issue is the specification depends directly on Spatialite. The beauty of using Sqlite is that it ships with practically everything, so an implementor can easily read it or even write to it without having to install any additional libraries. It ships on android phones, it ships with browsers, etc. Spatialite lib does not ship with much at all. So it's an additional dependency that I believe will greatly hinder adoption, since it won't be readable except by people who have taken the time to include geospatial libraries.
> 
> Now what I believe could work well is specifying a blob geometry. This could just use spatialite's nicely defined binary spec, or it could be something else. Sqlite is great in that if an extension is not installed then it just returns the data as blobs. So an implementor who does not have access to spatialite on their sqlite could still read a geopackage vector file and know how to unpack the blob and use that geospatial coordinate. It doesn't matter that sqlite has no geometry blob already defined, it's a system that doesn't depend on needing that in the main specification. If it was just a geometry blob from sqlite then implementors wouldn't have a spatial index or all the spatial operations in simple features for sql. But many cases won't need that. A mobile device might just have 50 points, where a spatial index is useless. They may just want to read and write points. Additionally other libraries may offer some spatial capabilities on their own, and could do more but not have to figure out spatialite lib dependency management. Using spatialite's binary definition as the blob could work quite well, since that system and all the code already written to leverage it could use and take advantage of any geopackage vector geometry blob.
> 
> 1. Requirement: General (? - I'm not sure what number I'm supposed to put here)
> 
> 
> 2. Implementation Specification Section number: 9
> 
> 
> 3. Criticality: Major
> 
> 
> 4. Comments/justifications for changes: 
> 
> I've been informed that there is some active discussion of this on the GeoPackage SWG list, but I wanted to sound in with my opinion on standardizing an API versus standardizing the geometry format. I strongly feel the only part that should be standardized is the geometry format. It should be a single binary format. If desired the API could be standardized in an optional specification, that lays out all the table names and triggers. The core standard should just be the geometry blob, the underlying sqlite file format. That's what will get passed around. That's what needs to be read. I believe it's ok to specify it as the binary that results from sqlite with geometries stored in a certain way. An alternative would be to fully specify the binary structure of sqlite. But just specifying the table structure could lead to unanticipated results. One of our developers suggested doing an java implementation of the specification. As specified this would mean we'd match the table structures and api's, like with jts plus an embedded database like h2. Like https://github.com/jdeolive/geodb this could match the specification, except for the parts that say it requires libspatialite. But it'd result in a totally different binary format. I've heard there is discussion of multiple binary geometry formats, and just 'focusing on the api'. I believe this is also the wrong approach. This will greatly decrease interoperability, as people will make readers and writers for the one that makes sense to them. And then getting a geopackage vector format may not actually be able to be read. 
> 
> As a standards organization the OGC best serves its users and members by choosing exactly one format. This has been an increasing problem in recent specifications. The original get vs post bindings made some sense, one offered an easy way to do things through the browser, the other often had more options and possibilities. But specifications like GeoSynchronization service are frankly ruined by 4 different bindings. As an implementor you have no idea which to do. They don't even recommend one as the best way. So to implement the spec at all you have to do all of them, or risk that the other end won't be able to read it. At OpenGeo we experienced this directly with the WMTS specification. We just had funding for one of the bindings, and our client funded a front end for it that read the other binding. So even though they had funded implementation of the specification since they didn't fund it all or coordinate on which to have both do they got nothing. Specifications should be one standard, not 4, or even 2. So please just pick one geometry format, and standardize on that. The API to access it and maintain consistency should be a separate specification that builds on it (and it should not be included in the main specification as optional conformance classes)
> 
> 
> 1. Requirement: General (? - I'm not sure what number I'm supposed to put here)
> 
> 
> 2. Implementation Specification Section number: 9
> 
> 
> 3. Criticality: Major
> 
> 
> 4. Comments/justifications for changes:
> 
> All optional conformance classes should be moved to a separate specification or appendix. I realize this is not the current OGC way of doing things, but I believe it greatly improves readability. The specification should also not spend so much time listing every single geometry operation. Especially since it's an exact repeat of the capabilities of spatialite, without saying that. It should be up front that spatialite is required and the only working implementation (though I don't think it should be required, see other comments). It honestly took me 20 minutes to figure out that this was just a standardization of spatialite. Though I think standardization of sqlite using spatialite geometry format is far more powerful I do think standardizing on spatialite could do a lot. But in the spirit of having the specification communicate just the right information it should say that up front.  
> 
> The specification is also made way more confusing and unreadable with the trigger statements scattered through out. These should move to a 'geopackage vector consistency api' standard, not cluttering up the main core standard. Most people will likely just use spatialite, so won't need to bother with reading the whole thing, they can just trust that they're using the standard reference implementation and it's taking care of all the details. So all the constraint checking can be in a side best practices paper on using spatialite to implement the core. Or it could be a standard on the 'api' of all the sql statements and table structures that can make it so.
> 
> 
> 1. Requirement: 18/19
> 
> 2. Implementation Specification Section number: 9.4
> 
> 
> 3. Criticality: Minor / Editoral
> 
> 
> 4. Comments/justifications for changes:
> 
> The  '“gB” and “gS” architectures' are super confusing and don't seem to add any value. I think I understand this stuff pretty well and am still not sure of the differences and when I might want to use one or the other, or if I even have the possibility in spatialite. I'd say just pick gB for people, standardize on it for now. If core tech improvements make the other possible and more attractive then put it in a future version of the spec. Reading that paragraph feels like an engineering report on the possibilities, not a spec providing guidance to people.
> 
> 
> 1. Requirement: 25
> 
> 
> 2. Implementation Specification Section number: 9
> 
> 
> 3. Criticality: Minor
> 
> 
> 4. Comments/justifications for changes:
> 
> I don't think that a spatial index should be a requirement. This goes a bit back up to the core points above about just sqlite. But indexing should be an optional piece, not in the core spec, at least not initially. Shapefile is actually a good example, where a standard index file evolved. But we should let implementors experiment with indexing schemes and then standardize what works best. Spatial indexing should be an extension to the core vector geopackage, not a required part of it. I realize this is a different philosophy than most OGC specs, but I think it's something that can make the specs much better. Keep them focused on meeting the most needs, and put the more obscure use cases in extensions to the core. I admit that many will want a spatial index. But as far as I know the driver for geopackage is mobile devices, and many of those will just be a small number of point features that a user is editing, where a spatial index doesn't add much at all.
> 
> 
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 9.3
> 
> 3. Criticality: Minor / Editorial
> 
> 4. Comments/justifications for changes:
> 
> On page 20 the specification says: 'SQLite does not have separate catalogs or schemas, so the f_table_catalog and f_table_schema columns are meaningless in an SQLite GPKG container....' That whole page again reads more like an engineering report. It's an evaluation of the simple features for sql specification against the capabilities of sqlite. The spec doesn't need a list of the non-relevant ones and the reasons they aren't relevant. It just needs the list of ones to implement. Again, this comes down to the fact that we actually _want_ sqlite (with or without spatialite lib, geos lib and proj lib) to be the only implementation of it, because we want that file format it emits to be standard and shared across systems. So we don't need to talk philosophically about how it ideally would implement simple features for sql or sqlmm. Once it can then we just update the spec for a new version that understands that.
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 9.6
> 
> 3. Criticality: Editorial
> 
> 4. Comments/justifications for changes:
> 
> On page 37 'Note3: SpatiaLite is currently the only known vector feature store based on SQLite that meets the specifications documented above for vector features and SQL geometry routines.' This line and the following paragraph seem entirely unnecessary, since REQ 44 on page 36 says that it shall be a 'SQLite database with libspatialite loaded to provide SpatiaLite extensions of  version 3.0.1'. The spec doesn't just specify the routines, it requires the actual library. Which again, I don't think is a bad thing, it should just be clear up front and shouldn't waste a whole bunch of people's time repeating all the capabilities that spatialite offers and how to set up its triggers. That should be a complementary best practices or engineering paper.
> 
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 9.6
> 
> 3. Criticality: Major
> 
> 4. Comments/justifications for changes:
> 
> On page 36, there's a microsoft word comment on spatialite 'The GeoPackage Software Working Group (SWG) should discuss further revisions to the specification to enable development of other reference implementations.' This seems to me to be a very, very bad thing since then we will end up with multiple binary files for databases that meet the requirements (though obviously those requirements would have to be relaxed from requiring lib spatialite). And users won't know which one they're supposed to use, the one produced by C or Java or some other tool. There _should_ be just one reference implementation, and indeed it should be explicitly specified. Or if that doesn't fly then just specify the binary file format. That could then be read by other implementations, and it wouldn't lead to many different formats that all have the table structures, geometry operations and constraints done right but store the data differently.
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 10
> 
> 3. Criticality: Major
> 
> 4. Comments/justifications for changes:
> 
> I spent less total time on this section, so don't have as many specific comments. But my general sentiment from vectors is even more true here. The tile part of the specification should be done with pure sqlite, no dependency on spatialite/rasterlite. And it should just focus on tiles, not on a view structure of raster data. I think there's actually a great logical way to make this in to two complementary specifications. 
> 
> The tile portion should be just some small extensions on MBTiles to handle multiple projections, which I understand is the big immediate need that MBTiles is not covering. But the specification should strive to cover exactly that need, not 5 more future needs. At some point those should be covered, when it's clear that the core is working quite well and people naturally extend it to try more things. Once a few people have tried new things then the core can be extended. Ideally the tile portion of the specification is super legible to anyone who has implemented MBTiles, they'd be able to grok in a couple minutes that they just have to tweak a few things to handle additional projections. It should be nice and simple, no more than 5 pages. Ideally it could eventually merge with MBTiles, in an MBTiles 2.0 once they see the need to handle more projections. Or even more ideally they just point at the geopackage tile spec as the new way of doing things. But that will _only_ happen if it's super simple, like MBTiles, and then extends for just projections. 
> 
> And again, it is essential this core is just sqlite. It should be able to work on any existing sqlite system, not requiring spatial extensions, and not requiring lots of tables and triggers. Tiles are quite simple and MBTiles has proven this is possible. This is a great opportunity for the OGC specifications to simply extend what has already gotten great uptake. A counter example of where the OGC has done a poor job of this is WMTS. The TMS specification was nice and simple, and WMTS introduced way too much complexity. It took our GeoWebCache developers 10 times as long to implement, as it added lots of complexity to handle use cases most don't care about.
> 
> The functionality that includes views on raster data though seems like an ideal extension. It offers more capabilities on top of the core tiling, representing the tiles as SQL Views on top of the core raster types. 
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 9.6
> 
> 3. Criticality: Editorial
> 
> 4. Comments/justifications for changes:
> 
> It would be good to remove all reference to rasterlite if it is not actually required. I walked away with the impression that it was, though a Geopackage SWG member pointed out to me it wasn't. It is so heavily featured though that one assumes it must be. I think that type of information belongs in an engineering report, not in the spec proper. With one exception, and that would be if it could save lots of space by just referencing spatialite's raster operations. Also all the optional conformance stuff, triggers and the like, should go in a separate specification, to keep the core clear. The specification should just describe the table structure, and then a best practices can include a list of triggers to help maintain the consistency of that table structure.
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 11
> 
> 3. Criticality: Major
> 
> 4. Comments/justifications for changes:
> 
> The metadata section of the specification is actually quite well done. It is not required, and nice and short. It depends on other specifications, and for the most part just references them. The bit of listing scope codes is actually quite useful, citing where they come from, and then listing exactly the ones that are relevant for this part of the specification. I think the metadata section could be a great stand alone specification, that complements any of the other geopackage specifications. Each can refer to the metadata spec, as the recommended way to add additional metadata. 
> 
> One thing that could be nice is a recommended, though not required, metadata format. Like iso19139, something widely used. But let people know it can be others. But someone who doesn't know otherwise but wants to add some metadata can have a recommendation of which to use. Those who care about a particular metadata format can override that. Europe might additionally specify that geopackages from government sources should all include INSPIRE metadata documents.
> 
> Reiterating what I said in other sections I do think the listing of triggers should be removed from the specification proper. The specification should just list what a properly implemented table looks like. A best practices paper can list the sql triggers.
> 
> 1. Requirement: General 
> 
> 2. Implementation Specification Section number: 13
> 
> 3. Criticality: Major
> 
> 4. Comments/justifications for changes:
> 
> The manifest document should also be its own specification. Most all other ones will refer to it. But I believe the others should be designed in such a way that they don't _require_ it to be there to do anything useful. It should just provide additional information about where a geopackage might fit in to a broader context. 
> 
> I need to spend some more time thinking about it, but I think having it be an xml document is weird. Mostly in regards to the expectations of the rest of the specification. The rest is all about an API for developers to access, a nice sql api to do a lot. But the xml document is more of a raw thing that requires libraries to read it. We should be providing developers a consistent interface. One way to do that is to ship a geopackage api that includes good xml parsing stuff. And then documents the calls to get at the information in the manifest. Alternatively the manifest information could be represented as tables, so that it is a consistent API. But a big xml document smashed in to the spec makes for an inconsistent api, and greatly raises the barriers to implementation. It requires developers who are fluent in both xml access and sql. It can be argued that both are fairly standard skills for developers. But most are likely stronger in one or the other, so you end up being as hard as their biggest weakness. I've heard an argument that the manifest comes from some other OGC documents. 
> 
> The information contained in the manifest looks more or less ok. But it feels like that part of the spec was written by someone who just wasn't that comfortable with the sql api's that make the rest of the spec, so just wrote from their experience with ows context and atom, and shoved it in to the field. I think geopackage should not depend on an OGC-fluent audience, but an audience of potentially geo-naive implementors. So the manifest should be consistent with the rest of the specification, not consistent with OGC xml.
> 
> _______________________________________________
> Requests mailing list
> Requests at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/requests

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20130208/0a9ae07f/attachment-0001.htm>


More information about the Requests mailing list