Tiles that are smaller than the specified width/height

[jyutzler]

The question is whether we need to change the specification regarding tiles that are not as large as the specified dimensions. Two possible approaches come to mind:

• Add or update a requirement to indicate that tiles must match the specified dimensions
• Update the surrounding text to provide guidance on what clients should do in these situations

Or we could do nothing.

From the mailing list:

AFAICS nothing in the spec strongly binds (ie as a requirement or a test in the ATS) the values
of (tile_width, tile_height) found in gpkg_tile_matrix with the actual dimensions of the
images stored in the tile pyramid user data table. Table 10 mentions though tile_matrix :
"Tile width in pixels (>= 1)for this zoom level" (and similar for tile_height).

Is there an implicit requirement that the dimensions of images in the tile pyramid user data
table should be exactly (tile_width, tile_height) ?

Making them greater than that does not make sense of course, but one could imagine that
for images at the right or bottom border of a raster coverage to be truncated. For example if
you have a raster of size 300x300 with tiles of 256x256, the right tile could be just 44 pixel
wide. Would that be valid ? If not, perhaps that could be mentioned ("tiles should not be
truncated, but padded to reach the tile_width x tile_height dimensions")

My response:

You are right that this is behavior is unspecified. I am reluctant to add a new requirement that the tile dimensions in gpkg_tile_matrix to match the actual tile_data column in the tile pyramid user data table simply because this will be difficult to test. An explanatory note is more likely, but then what would the tile be padded with? There is no concept of DATA_NULL in tiles like there is in 2d-gridded-coverage.

His reply:

If those partial tiles have an alpha channel like a PNG RGBA or Grey+Alpha tile, then setting the alpha to 0 in the padding areas seems to me to be the most reasonable behaviour (and that's what the GDAL writer will do for those border tiles with its default PNG_JPEG tile format strategy). Otherwise this is context dependent of what the background color should be : black, white, etc...

[jyutzler]

One of the "features" of the tiles design is that we do not specify that all tiles must be one filetype or another. This was deliberate and one of the reasons for this was to better support boundary situations. While JPG is preferred for imagery because of its relatively better image compression, PNG is suitable for the edges of a coverage because the alpha channel can be used. Because of this, I don't see any reason to change anything in the spec. (We'll see what the others say tomorrow.)

I acknowledge that we need to do a better job getting guidance like this onto geopackage.org.

[jyutzler]

At the SWG today we decided that there is no action required to the SWG, but that we should add some implementation guidance to geopackage.org. This ticket will stay open until that happens.