[Requests] GeoPackage comments from OpenGeo

Chris Holmes cholmes at opengeo.org
Thu Feb 7 19:51:37 EST 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20130207/24b49c7f/attachment-0001.htm>


More information about the Requests mailing list