ryanfranz
commented
10 months ago @jerstlouis So on the CDB (CDB 1.x) side, there has always been a requirement that if there is higher resolution data, you always have a file, even if that file is empty or zero sized. It is an indication that even if no data exists for this area at a certain resolution, there is data at higher/finer resolutions. So an application like ours might start by loading level 0 in CDB 1.x. If the file does not exist, then there is no high resolution data. If a file exists, even if empty, we will load the higher level when it is needed (taking the feature size or raster pixel size and the distance to it (even calculating look angle) and converting to screen space error to decide this). We continue doing this, loading higher tiles until we run out of tiles (or files) to load. Essentially, at that point we have a raster pyramid in memory and we keep track of areas/tiles that might have more resolution and areas that do not.
For CDB 2.0, I would assume the difference would be, whether a row exists in the tile table (even if null) or no row exists. I would like to see a partial restriction of the GeoPackage flexibility about sparse data, that if data exists, then all lower resolution tiles exist, even if they are empty.
jerstlouis
We have been considering the case where you have a heterogeneous tiled imagery layer which was sourced from various datasets, and may have different resolutions (maximum zoom levels) for different geospatial extents.
Our visualization client currently struggles with this -- we usually expect a consistent maximum layer where separate such layers would be used for identifying these areas with different resolutions, though in the past we had to use some work arounds for tile servers returning no data for some areas at a higher level, but returning valid data (of the same area) at a lower resolution. These work arounds, as I had implemented them, caused their own problems.
@ryanfranz
So I have thought a bit more about this missing tile problem, and I still think there is an issue with automatically trying to fall back to trying lower resolution when looking up a tile in a GeoPackage finds no record, or requesting a high resolution tiles returns a 404 or 204.
It may in fact be that the reason the low resolution tile exists is because it encompasses both an area that has data and an area that does not have data (e.g., water), which in that low resolution tile might be 0-alpha (e.g., in GeoTIFF, PNG, JPEG XL). This would also be a common scenario with vector tiles. In this case, you really do not want to be using the lower resolution tile, since it includes no additional information (and if you do display it, it would need to be rendered in addition to and underneath the higher resolution tile that does exist which overlaps with the low resolution one).
@jyutzler @joanma747
What would be the current established or best practice for handling such scenarios in GeoPackage and WMTS / OGC API - Tiles ?
Very much related to this is the concept of scenes which allow describing such distinct individual components of an overall data layer -- I just proposed a Scenes requirements class to OGC API - Coverages (and could easily extend to Maps, Tiles, even Features).
Thanks!