I've discovered some interesting behaviour in the GeoPackage Raster Mosaic
implementation over the last few days.
I tried viewing a GeoPackage generated from the GeoServer GeoPackage WMS
output format in QGIS, and observed that tile order is reversed along the
y-axis.
QGIS used GDAL for parsing GeoPackages. After running this issue by the
GDAL team, I was directed to this line of the OGC GeoPackage spec
<http://www.geopackage.org/spec/#tile_matrix>:
The tile coordinate (0,0) always refers to the tile in the upper left
> corner of the tile matrix at any zoom level, regardless of the actual
> availability of that tile
Adding some test cases to the GeoTools GeoPackage plugin, I can confirm
that GeoTools gets this order wrong. Among other things, this means that
GeoTools / GeoServer will incorrectly read valid GeoPackage files. A fix
can be found here: https://github.com/geotools/geotools/pull/1567
Moving along to GeoServer, it appears there are similar problems with the
GeoServer GeoPackage Community module, namely in the
GeoPackageGetMapOutputFormat.
I believe I have a fix, but am currently being slowed down by the fact that
the GeoPackage module tests don't seem to be passing on master.
*This issue does bring up a problem*: Because GeoTools / GeoServer is
consistently wrong (a GeoPackage generated by GeoServer will be read in as
"correct"), this bug fix could cause problems for anyone who has solely
been using GeoPackage Rasters that were generated by GeoTools / GeoServer.
For more details:
https://osgeo-org.atlassian.net/browse/GEOT-5715
https://osgeo-org.atlassian.net/browse/GEOS-8112
https://trac.osgeo.org/gdal/ticket/6871
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
