Does anyone have an objection to incorporating this discussion into the two public Google groups?

On 3/8/2012 9:27 AM, Backe, Kevin AGC wrote:

Folks,

 

Chris makes a good point about having this discussion on the open list.   Let?s post this dialog (given all contributors are ok with doing so) and continue all this discussion on this google groups.  Kevin

 

From: cholmes@openplans.org [mailto:cholmes@openplans.org] On Behalf Of Chris Holmes
Sent: Thursday, March 08, 2012 9:05 AM
To: pauld@imagemattersllc.com
Cc: Christopher Tucker; Backe, Kevin AGC; Eddie Pickle; Brett Antonides; Paul Ramsey
Subject: Re: Any reason not to use SpatiaLite as the basis?

 

 

Interesting discussion. But _why_ is this not happening on the open lists that we created to discuss these things? That's the whole point of an open spec for me, you have these discussions in the open, not pre-determining everything before you start talking about it in public. Can we move this there? I even think discussions about licensing and building on spatialite and all that should be in public too, as it could be that the spatialite guys themselves can give insight, etc. 

 

I think that the conversation wanted to see multiple GPKG specs that were modular.  GPKG-Tiles, GPKG-Features, GPKG-Grids.

 

OK, but this is supposed to be a >package< spec, and it also needs to include a manifest as you mentioned below.  I don't see how separating the pieces makes it any easier to read or apply them.  I don't have any problem with making separate sections and conformance classes for each piece, or with starting with GPKG-Tiles since that is the most pressing need.

 

 

I feel fairly strongly that these should be in separate specs. Yes, it's a package spec, but it's not packaging pieces that are already known. So if someone is just interested in implementing tiles, or just interested in features, then they'd have to read a full spec talking all about packages and manifests and other things not of interest. And a developer who is not bought in to OGC will just go somewhere else, find a simpler more concise standard for just what they need. But if they are able to find just the concise spec that mentions it can easily fit in with other formats, but just gives guidance on what they need, then they can feel sure that it's ok for them to just implement that.

 

I actually think it's even not stellar positioning to call them GPKG-Tiles and GPKG-Features, as it implies they're only useful in a bigger part of some gpkg, that they couldn't be used standalone. I think they should be quite standalone, and we should focus on making very solid standalone specs for tiles and for vectors, and only then worry about bringing them together in a single package. If we design the package first then we make an assumption that all will use the same package and will end up with a spec that only people who need all would even look at.

 

 

 

And, any such use case that included #3 above, would require implementation on SpatiaLite.  But, any implementation that included only #1 and #2 could be done on SQLite, but with a manifest.

 

Is this right?  Or am I missing something?

The other major MBTiles shortcoming is being able to address only one image tile pyramid.  This of course was by design as it is intended to support multi-resolution web display of a single map.  The DevSeed / MapBox folks said they have no intention of extending MBTiles to support multiple pyramids, but have no problem with us using MBTiles defined in views as an interface to one RasterLite pyramid at a time. 

 

I do think there needs to be more research in to performance of tiles from sqlite before we home in on it too much. The stuff the thermopylae guys I think said scared me about it not performing well enough under certain scenarios. Ben Tuttle said we should look in to mapsforge's tile format - http://code.google.com/p/mapsforge/ And I believe that's more similar to what esri is doing on their mobile tile formats. Should get what the exact conditions that sqlite may break down for tile access and test those ourselves.

 

They are also not interested in getting MBTiles published as an OGC standard, but are not opposed to us doing so.  If we select it as a GPKG-Tiles interface, I think we should try to find 2 implementers to put it through the OGC RFC process, so it is a specification from an international "voluntary consensus standards body" per http://standards.gov/a119fr.cfm and not just an OS web page, no matter how useful and widely adopted.

 

 

I'm definitely for putting through the OGC process eventually. But I'd focus first on getting the 'OS web page' useful and widely adopted first, to get at least three or four real implementors - and not only implementors that are paid by funders to meet their needs (no fingers, I'm counting us in that category too). Getting it useful and widely adopted is a challenge. And I believe it starts by opening up these discussions as early as possible. We don't need to invite everyone and their mother to that list, but we do need to have discussions there so that everything talked about is archived and people can trace back why things were decided one way or another.

 

Chris

 

 

 

 

Chris

703-981-9373

 

 

On Mar 2, 2012, at 10:59 AM, Backe, Kevin AGC wrote:

Folks,

 

By our internal analysis SpatiaLite appears to be a good technical solution for the geopackaging spec for feature data.  Therefore, without an significant dissenting opinions will move forward using SpatiaLite as part of the framework for a Geopackage specification as well as reference implementation.  Please let us know ASAP if you have any show-stopper issues about using SpatiaLite.

 

I am not sure we have all the information we need about copyright and source control to make a final decision about using SpatiaLite as part of specification.  We understand we need to do more to investigation and communication with Furieri about the copyright.  Paul informed me and Nathan that it is entirely possible to backup and develop our own code since much of SpatiaLite was based upon other well know open source geospatial documentation.  (However, SpatiaLite provide a good foundation that permits us to save time and money on development costs.)

 

Please feel free to email to others that are supporting this effort.  ?Kevin