NSG GeoPackage Raster Tile Support

[geospatialmapmashup]

Can you please add support in all the Libraries for NSG GPKG Support

[bosborn]

I've read through the NSG spec a few times now. The libraries support everything in the NSG spec except for SRS organization codes of NGA. I've left the library specific tickets open for tracking:

• NGA NSG PROFILE geopackage-android#42
• NSG 2.0 GeoPackage Tiling Profile Support? geopackage-android-map#6
• ngageoint/geopackage-mapcache-android (no issue)
• NGA NSG PROFILE geopackage-ios#35
• NSG GeoPackage 2.0 Tiling Profile Support? geopackage-mapcache-ios#22
• NSG Profile Support geopackage-java#36
• NGA NSG PROFILE geopackage-js#97
• NSG GeoPackage 2.0 Support mage-android#28
• GeoPackage NSG 2.0 Tiling Profile Support? mage-ios#62

Anything using the EPSG organization should work. Nothing in the NSG spec built on top of the OGC GeoPackage spec should break any core functionality. What additional "NSG GeoPackage Raster Tile Support" issue are you referring to?

The libraries support and/or do not prohibit the NSG requirements of:

• File Naming - ex: “AGC_BUCK_Ft-Bliss_14-20_v1-0_29AUG2016.gpkg”
• SRS values of EPSG (currently no support for NGA)
• Metadata and Metadata References
• All listed data validity requirements
• Tile sizes and factors
• Feature extensions

I ran through the NSG GeoPackages here and they almost all function correctly. There was a bug in geopackage-js using proj4js on the Blue Marble GeoPackage causing high level and edge tiles to not display. This has been fixed by @danielbarela.

Please feel free to create library specific issues including sample files and issues you are seeing. This will help us identify issues, resolve problems, and improve the libraries. These are license friendly open source libraries often maintained with less than FTE, so issues and pull requests are welcome.

For SRS NGA organization codes, we need a custom or license-friendly WKT coordinate parsing solution. Until then there are some possible work arounds including manually setting the proj4 value for an organization code or adding a NGA proj4 property file. This would require obtaining a list of proj4 values for each NGA organization srs_id WKT value in the NSG spec 7.2 Well Known Text section.

[geospatialmapmashup]

The problem with the NSG GPKG that I have is the Tile Numbers (Zoom Column Rows) don't match Google XYZ or TMS tile numbers. So the data will display but be in the wrong place! I have several NSG GPKG from the NGA/DoD Map of the World and from the US Navy Research Lab https://geoint.nrlssc.navy.mil/gpkg/

[geospatialmapmashup]

I QGIS with the Tile Layer Plugin but you can also go to http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/

[geospatialmapmashup]

In addition, the NSG GPKG I've gotten or downloaded don't have any metadata records denoting they are special or no GeoPackage Extension. It's hard to expect a mapping client just to work without noting the difference between XYZ/TMS and NSG

[bosborn]

The NSG spec does not redefine how tiles are stored in a GeoPackage. It only defines permitted extensions and restrictions on top of the OGC GeoPackage spec. It is basically a spec on top of a spec, but does not change anything in the base spec. See this answer for more details. Any implementation that supports base GeoPackage functionality also supports NSG GeoPackages.

The problem with the NSG GPKG that I have is the Tile Numbers (Zoom Column Rows) don't match Google XYZ or TMS tile numbers.

This should be the assumption for all GeoPackages, not just NSG. For full details you can view the tiles section of the spec. In summary, the Tile Matrix Set defines the exact bounds of the tiles while the Tile Matrix defines the structure of the tiles within each zoom level. The tiles in the user table contain zoom, column, and row values defining where they belong in the defined Tile Matrix Set and Tile Matrix. This has nothing to do with XYZ or TMS tiles. Those transformations are handled elsewhere in the libraries. If you are using the libraries to manually read those tile rows with the assumption the coordinates map to an alternate tile system, that would cause expected problems.

In addition, the NSG GPKG I've gotten or downloaded don't have any metadata records denoting they are special or no GeoPackage Extension.

There is no additional metadata or extensions required as the dimensions are mathematically defined by the Tile Matrix Set and Tile Matrix.

Here are some U.S. Naval Research Laboratory NSG GeoPackage examples loaded into geopackage-js (you can also view them in Android, iOS, or pull the tiles out in Java):

• World Port Index Vector
• Blue Marble
• Black Marble
• Aero Enroute Chart Features USA

If you are able to provide detailed steps, examples, source code, and/or sample files that demonstrate the erroneous results you are seeing, we are happy to help. These libraries do currently support NSG GeoPackages using a Spatial Reference System organization of EPSG.

[bosborn]

Also note that the raw tiles from the tile table may not be projected as Web Mercator. And even when they are, they may not have the same tile boundaries as XYZ or TMS tiles. These libraries handle the image projections and cropping to obtain the requested XYZ or TMS tile.

[geospatialmapmashup]

Not understanding how to get the data to show up in the right place. The Z-zoom/Column-X/Row-Y.png
don't work. I understand Spatial Reference Coordinate Systems and Proj4. Just don't know how to get the data to show up in the right place. I thought this would be handled by these libraries. We are using it in Android, iOS and JavaScript and we are stuck at this point and Can not support NSG Spec GPKG.

[danielbarela]

GeoPackageJS has a convenience method module.exports.getTileFromXYZ = function(geopackage, table, x, y, z, width, height, callback) which will get the correct tile(s) from the GeoPackage that correspond to the xyz tile specified and will callback with the image. Please see line 444 in https://github.com/ngageoint/geopackage-js/blob/master/docs/common.js for an example.

[bosborn]

These libraries handle retrieving projected bounded tiles in addition to the raw tiles from the user tile table. It sounds like your issue is not NSG related as any GeoPackage would cause you issues when not saved to mirror XYZ tiles. Here are a few to try from the OGC GeoPackage sample data:

• Tiles and a vegetation vector layer around Washington DC
• Tiles and Vector Features for Port au Prince, Haiti

Android

If you are using the default Android map, geopackage-mapcache-android is an entire app demonstrating usage. An APK can be downloaded here. It relies on geopackage-android-map.

Add a tile layer to the map:

TileDao tileDao = geoPackage.getTileDao(tileTable);
TileProvider overlay = GeoPackageOverlayFactory.getTileProvider(tileDao);
TileOverlayOptions overlayOptions = new TileOverlayOptions();
overlayOptions.tileProvider(overlay);
overlayOptions.zIndex(-1);
map.addTileOverlay(overlayOptions);

If you want to pull out the tiles manually or use a different map that relies only on geopackage-android (something osmdroid does), see TileCreator or GeoPackageTileRetriever.

TileCreator allows you to pull out a tile for a provided bounding box in either the tile projection or a request projection. TileRetriever allows you to pull out a tile for a XYZ coordinate. You can use it with a TMS coordinate by converting the Y value using this method, which is something geopackage-java does.

iOS

geopackage-mapcache-ios is an entire app demonstrating usage that can be built and run.

GPKGTileDao *tileDao = [geoPackage getTileDaoWithTableName:tileTable];
MKTileOverlay *tileOverlay = [GPKGOverlayFactory getTileOverlayWithTileDao:tileDao];
tileOverlay.canReplaceMapContent = false;
[mapView addOverlay:tileOverlay];

Similar to Android, see GPKGTileCreator for retrieving tiles by bounding box and GPKGGeoPackageTileRetriever for retrieving tiles by XYZ (or TMS).

[bosborn]

NSG is fully supported except for NGA authored CRS WKT coordinate system values. This can be supported currently by providing those values in advance. Will be handled automatically in the future as part of the following:

• Java/Android: Add WKT definition parsing into proj4 parameters simple-features-proj-java#1
• iOS: Add WKT definition parsing into proj4 parameters simple-features-proj-ios#1

[bosborn]

Complete and explicit DGIWG (Defence Geospatial Information Working Group) GeoPackage Profile support for the current working version, previously known as the NSG Profile, has been added in the following libraries:

• Java Core
• Java
• Android
• iOS