Questions arising through DGIWG Profile development

[jyutzler]

1. [ ] Metadata md_scope. The md_scope value for the gpkg_metadata table does not have a code for a tileSet (layer) metadata in GeoPackage. The md_scope code of 016 for a tile implies a level for a single tile, though metadata for each tile seems excessive. In the profile, DGIWG is using the value 015, model, to represent metadata for the tileSet because DGIWG doesn’t anticipate having GeoPackages that contain models. Will using the model code going to create interoperability problems or is there another md_scope value that can be purposed for tileSet metadata?
2. [ ] Zoom levels. For a raster tileSet that doesn’t have multiple zoom levels in a particular projection such as Lambert Conformal Conic, DGIWG allows the gpkg_tile_matrix table to contain a single tile matrix set for the scale of the product (e.g., 1:12,500, 1:50,000, 1:100,000). Does anyone have experience using GeoPackage for a single zoom level?
3. [ ] R-Tree. The R-Tree extension is mandated by DGIWG for vector data. A reviewer stated that R-tree isn’t necessary for “small” amounts of vector data. DGIWG decided not to make R-Tree a conditional requirement because the conditions were subjective. Can anyone recommend a minimum number of features or area threshold that requires the R-Tree extension for performance?
4. [ ] Bounding Box comparison. A reviewer noted that enforcing validation constraints to compare an dataset’s bounding box with the stated layer and CRS bounding box could fail validation due to rounding errors in floating point numbers. Has anyone found a need to use an error threshold “margin_x” and “margin_y” in the within bbox calculations due to rounding errors ? If so, does anyone have a recommended error margin for bbox comparisons?
5. [ ] BBox size. Requiring a 256 pixel tile size (requirement R20) does not account for rows and columns not divisible by 256. How are geopackage handling tiles on the periphery of the layer’s extent that are less than 256 pixels in width or height? Are the pixles outside the bounds of the dataset equal to noData or black or transparent?

[jamesresslernga]

On R-Tree, DGIWG P5 decided to keep R-Tree as Mandatory extension without condition because there is not a clear minimum number of features or area threshold to establish and enforce the condition to require the R-Tree extension for performance On Bounding box comparison, DGiWG P5 decided to not specific they error marges On TilleSize, DGIWG to took no position how to populate the missing area's pixels. Last bullet should be- labeled "Tile Size" instead of BBox size.

[cnreediii]

@jamesresslernga

Something got garbled here: On Bounding box comparison, DGiWG P5 decided to not specific they error marges

[jamesresslernga]

Correction On Bounding box comparison. DGIWG P5 decided to not specify any X & Y error margins until a real-world case is found with GeoPackage that requires margins for an accurate query of geospatial layers in GeoPackage.

[jyutzler]

We discussed these questions during the last SWG meeting. Here are the responses.

1. There is such a paucity of metadata in the field that you can do whatever you want and it will be the standard. There is no serious risk of interoperability issues.
2. No one on the call had direct experience doing this, but the capability is explicitly allowed in the design. Any client system capable of querying the relevant tables (and not hard-coded to a single projection like EPSG:3857) should be able to handle this.
3. You probably won't like this answer, but it depends. For non-spatial queries, the r-tree index is irrelevant. On inserts/updates, the index is an impediment so for bulk operations you will probably want to temporarily drop the index and reinstate it. Beyond that, performance is as dependent on the operating environment as the number of features.
4. Yes, a bbox constraint was removed from the abstract test suite for this reason. Note this text in 1.3.1.1.2: "The bounding box (min_x, min_y, max_x, max_y) provides an informative bounding box of the content. Applications may use this bounding box as the extents of a default view but there are no requirements that this bounding box be exact or represent the minimum bounding box of the content. The values are in the units specified by that CRS."
5. R20 must refer to a requirement of the profile. It is not clear to us what CRS you are using and what the actual problem is.

[jamesresslernga]

Thank you for the response, Jeff. The comments are useful. On #5, the situation raised for am area not divisible by 256 and handles tiles on the edges of the bounding box that are less than 256 pixels. Does the GeoPackage provide null data beyond the edge or black fill the edge tiles outside the bbox? We decided by using Tile Matrix definitions from OGC 17-083r2, the TileWidth and TileHeight are predefined as 256 for each zoom level, so this situation would not arise.

[jyutzler]

I don't think we specify what the data looks like beyond the boundary. Since PNG allows transparency, it would make sense to use transparency for NO_DATA. For JPG, it would presumably be black. Do you think we should revise any part of the standard to clarify this?

[jratike80]

Sections "Tile encoding PNG" and "Tile encoding JPEG" handle this case indirectly. PNG supports transparency/nodata while JPEG does not. A common practice is that the partial tiles are saved as PNG and filled with nodata. The full tiles may be either PNG or JPEG. A better explanation can be found from the GDAL documentation https://gdal.org/drivers/raster/gpkg.html#tiled-rasters. Maybe the GeoPackage standard does not clearly say what was the reason for allowing this:

Requirements 36 and 37 in combination allow a tile pyramid user data table to contain PNG or JPG tiles. They may be mixed and matched within the same table.

However, I do not know if standard should mandate to use PNG filled with transparency for partial tiles. There may be use cases when users want to get just JPEG tiles even they cannot be made transparent in a reliable way because of lossy compression that is sometimes changing the nodata values to something else. Perhaps there could be a Best practice document that describes how it is possible to reach both good compression (JPEG) and support for nodata (PNG) at the same time when dealing with data like orthophotos.