Review Interoperability Issues in Tiling

[jyutzler]

The SWG will review the tile portion of the standard to determine if the interoperability issues observed in the GeoPackage Plugfest are due to the specification itself as opposed to a lack of profiling. If we find that the wording in the standard is unclear or otherwise wrong, we will issue a change request to the standard.

[jyutzler]

The plugfest interoperability issues and this email thread all deal with the same issue, what are the bounds of a tile pyramid for? I encourage all interested SWG members to join today's discussion.
More info here.

[pepijnve]

@jyutzler still surprised about the confusion presented in the referenced slide deck. In particular the title of slide 2 'what are these bounds for?'. The bounds in gpkg_tile_matrix_set define the spatial extent of the tile pyramid. Tile pyramids are allowed to be sparse. As a consequence the bounds in gpkg_tile_matrix_set might not be the MBR for the set of tiles in the tiles table.

In slide 6 there's a quote from Paul which surprised me as well. Using a GeoPackage as a local cache for a remote tile service is something Luciad was doing from day 1. IIRC we create a GeoPackage based on the metadata from the remote service but without any tiles in it. As tiles are retrieved they get stored in the GeoPackage.

On slide 7, those are AGC specific question I guess. Requiring global tile matrix sets will cause a loss of functionality wrt the current spec. There are plenty of WMTS datasets out there that use non-global pyramids that will no longer be convertible to GeoPackage.

[jyutzler]

@pepijnve Let's talk about non-global pyramids. Let's say for sake of argument that we're working in Web Mercator and we have imagery over a small region somewhere. The (for sake of a better term) RGi view is that the extent of that pyramid is the MBR of the tiles that make up that small region. For others it is the whole world. I can see how this disconnect arose. I am less clear on what to do about it.

Reading the tea leaves, I think we're headed to a(nother) corrigendum.

[pepijnve]

I don't think anything really needs to be "done" about this. Both are valid IMO. It probably does need to be clarified in the text that both can exist so clients shouldn't make assumptions either way.

[jyutzler]

I have tweaked the wording on the briefing (see "More info here" above) to prepare us for Tuesday's meeting. I would like to resolve this issue at that time.

[jyutzler]

Today the SWG agreed to reject the interpretation that bounding box described in 2.2.6.1.1 must represent tight bounds around the tiles that are present. The SWG agreed revise the wording in 2.2.6.1.1 to remove any ambiguity and to issue a corrigendum.

In addition, the SWG does not recommend the use of this bounding box (or even the actual contents of the tile pyramid itself) as a useful set of extents for any map view as there is no guarantee that either will be fit for purpose. Simply put, the data is not the map view. The GeoPackage / OWS Context joint working group is currently developing guidance on the use of OWS Context to describe map views that use data in a GeoPackage.

[bradh]

👍

[jyutzler]

At today's SWG we agreed that #112 resolved the issue. I will make sure this gets incorporated into the next corrigendum.