Closed eclectice closed 2 years ago
The Coordinate Reference System Well-Known Text in your GeoPackage(gpkg_spatial_ref_sys
definition
) does not appear to be valid. There is fallback logic for failed and/or invalid definitions. In your case, the error is logged and the projection is successfully retrieved through an authority/code lookup. Projections are cached to reduce re-parsing matching authority, code, and definitions.
Invalid:
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","9122"]]
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH]
Valid (by fixing the provided invalid, other valid versions exist):
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH]]
If you have control over the GeoPackage creation, update the definition. If you are provided the GeoPackage, I suggest contacting/informing the producer.
You are correct. It no longer displays the exception when I altered the definition of my Geopackage file in DB Browser for the SQLite tool for EPSG:3857 entry as follows:
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH]
]
The map with the CORRECT Coordinate Reference System Well-Known Text for EPSG:3857, however, has been relocated lower; it is intended to be inside the red bounding box provided by its tile data at the max zoom, as shown in the screenshot below:
The red bounding box registered coordinates at the max zoom level (in this case 19) as follows:
2022-04-12 11:20:59.200 12547-12547/? I/OsmDroid: Geopackage database(0:5312): tile(0:tiles) zoom(0:19), CRS (3857) => (4326), bounding box from (N=max_y=181232.194064, E=max_x=12310642.027497, S=min_y=150963.130863, W=min_x=12280525.838353) => bounding box to (N=max_y=1.638782, E=max_x=110.588379, S=min_y=1.365134, W=min_x=110.317841)
The logcat output above comes from this code snippet:
TileDao tileDao = open.getTileDao(tileTables.get(k));
final long MIN_ZOOM = tileDao.getMinZoom();
final long MAX_ZOOM = tileDao.getMaxZoom();
if (tileDao.getProjection().getCode().equals(String.valueOf(ProjectionConstants.EPSG_WEB_MERCATOR))) {
mil.nga.geopackage.BoundingBox boundingBox3 = tileDao.getBoundingBox(MAX_ZOOM);
double northOri = boundingBox3.getMaxLatitude(); //MaxY
double eastOri = boundingBox3.getMaxLongitude(); //MaxX
double southOri = boundingBox3.getMinLatitude(); //MinY
double westOri = boundingBox3.getMinLongitude(); //MinX
mil.nga.geopackage.BoundingBox boundingBox = null;
if (northOri > tileSystem.getMaxLatitude() || southOri < tileSystem.getMinLatitude()) {
ProjectionTransform transform = tileDao.getProjection().getTransformation(ProjectionConstants.EPSG_WORLD_GEODETIC_SYSTEM);
mil.nga.geopackage.BoundingBox boundingBox2 = new mil.nga.geopackage.BoundingBox(westOri, southOri, eastOri, northOri);
boundingBox = boundingBox2.transform(transform);
} else {
boundingBox = boundingBox3;
}
double north = Math.min(tileSystem.getMaxLatitude(), boundingBox.getMaxLatitude()); //MaxY
double east = boundingBox.getMaxLongitude(); //MaxX
double south = Math.max(tileSystem.getMinLatitude(), boundingBox.getMinLatitude()); //MinY
double west = boundingBox.getMinLongitude(); //MinX
org.osmdroid.util.BoundingBox bounds = new org.osmdroid.util.BoundingBox(north, east, south, west);
Log.i(IMapView.LOGTAG, String.format("Geopackage database(%d:%s): tile(%d:%s) zoom(%d:%d), CRS (%s) => (%s), bounding box from (N=max_y=%f, E=max_x=%f, S=min_y=%f, W=min_x=%f) => bounding box to (N=max_y=%f, E=max_x=%f, S=min_y=%f, W=min_x=%f)",
i, databases.get(i), k, tileTables.get(k),
(int) MIN_ZOOM, (int) MAX_ZOOM,
tileDao.getProjection().getCode(), String.valueOf(ProjectionConstants.EPSG_WORLD_GEODETIC_SYSTEM),
northOri, eastOri, southOri, westOri,
north, east, south, west));
//must project in WGS84 in OsmDroid
srcs.add(new SafGeopackageRasterTileSource(databases.get(i), tileTables.get(k), (int) MIN_ZOOM, (int) MAX_ZOOM, bounds));
}
If I import the Geopackage file with the INCORRECT Coordinate Reference System Well-Known Text for EPSG:3857, I got this screenshot in which the tiles are within the red bounding box:
The red bounding box registered coordinates at the max zoom level (in this case 19) as follows:
2022-04-12 11:54:22.510 30810-30810/? I/OsmDroid: Geopackage database(0:5312.corrupt): tile(0:tiles) zoom(0:19), CRS (3857) => (4326), bounding box from (N=max_y=181232.194064, E=max_x=12310642.027497, S=min_y=150963.130863, W=min_x=12280525.838353) => bounding box to (N=max_y=1.627817, E=max_x=110.588379, S=min_y=1.355998, W=min_x=110.317841)
There is a difference shown in the North and South component of the red bounding box for the CORRECT and INCORRECT Coordinate Reference System Well-Known Text for EPSG:3857.
Why is that?
EPSG 3857 is a special case that relies on the equator radius instead of the known ellipsoid. Add AUTHORITY["EPSG","3857"]
at the end of the CRS WKT to fix the projections.
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
AUTHORITY["EPSG","3857"]]
Wow, it's so simple once I learn about it. Thank you; it now works as intended, as shown below. I can finally rest in peace.
Please fill out as much known and relevant information as possible.
Version Information:
Expected Results:
Observed Results:
What happened instead? Despite the fact that the map is displayed when it is enabled after it is loaded, an error appears in the Android logcat twice while loading it. I'm curious as to why it displays such an error.
How often does this occur? It occurs whenever a new raster Geopackage file with Pseudo Mercator projection is attempted to be loaded into Mapcache. It also happens with previously loaded maps (with Pseudo Mercator projection) when the Mapcache is launched from the beginning.
Output:
Logcat
Steps to Reproduce:
Test Files:
Links to any files needed for testing? Due to non-disclosure with the government entity, I am unable to release my raster Geopackage file that uses Pseudo Mercator projection. However, I can offer a few necessary tables using the SQLite DB Browser:
DB Browser for SQLite tables
* gpkg_contentsAdditional Information: