Autodetect the max zoom level based on the highest resolution coverage #79

emxsys · 2017-07-27T15:13:31Z

Overriding findMaxZoomAuto to return the zoom level closest to the highest resolution coverage in the request.

Re: issue GeoPackages exported from Layer Preview do not have same fidelity as source imagery #75

…ghest resolution coverage in the request. - Re: issue #75

emxsys · 2017-07-27T15:15:00Z

@pdavidc You're review is welcome, but not required to move forward.

pdavidc · 2017-07-27T16:13:43Z

...dwind-gs-geopkg/src/main/java/gov/nasa/worldwind/gs/geopkg/GeoPackageGetMapOutputFormat.java

+                double e = Math.abs(g.getScaleDenominator() - reqScaleDenominator);
+                if (e > error) {
+                    break;
+                } else {


Is this conditional necessary? I think readability could be improved:

if (e > error) { break; } error = e; i++;

I concur. Thanks.

emxsys · 2017-07-28T13:30:24Z

Problem

When a GeoPackage-based layer is exported as a GeoPackage, the max zoom level is determined to be the max zoom level in the gridset (level 21), not the max level in the tileset.

This is problematic: it creates a request for a GeoPackage at the highest possible resolution, many levels greater than required, causing a seemingly never-end job that consumes large amounts of memory and disk resources.

The coverage object that provides the gridset is unaware of the actual number of levels in the tileset.

Options/Ideas

Possibly trim the gridset. This would have to be performed at the time the data store is created as the grid range is stored in the data store's XML.
Possibly interrogate the data store. Metadata? Metadata would have to be added to the coverage/data store instances.
Create a UI for exporting to a GeoPackage that doesn't depend on the ability to autodetect the max zoom level in this case, but instead relies on the user to select a max zoom level (with constraint).

…t) of the tiles in the GeoPackage. - Was returning the grid range of the entire grid level. - Added supporting code to compute the grid range. - Refactoring is needed. See TODO statements.

…ided by the GridCoverage2DReader. - Provides access to getOriginalGridRange for obtaining the width/height of a GeoPackage.

emxsys · 2017-07-28T21:14:41Z

@pdavidc I would appreciate a sanity check on the changes while I move into functional testing.

pdavidc

I have a few questions about the handling of GeoPackage tile matrices that I'm hoping have easy answers, or highlight a potential problem.

pdavidc · 2017-07-28T21:47:51Z

worldwind-gt-geopkg/src/main/java/gov/nasa/worldwind/geopkg/mosaic/GeoPackageReader.java

@@ -90,21 +90,44 @@
    protected File sourceFile;

    protected Map<String, TileEntry> tiles = new HashMap<String, TileEntry>();
+
+    // TODO: store these gridRanges in the TileEntry class
+    protected Map<String, GridEnvelope2D> gridRanges = new HashMap<String, GridEnvelope2D>();

    public GeoPackageReader(Object source, Hints hints) throws IOException {
        coverageFactory = CoverageFactoryFinder.getGridCoverageFactory(this.hints);


It appears that the hints argument is unused. Could it be that the object property hints is unnecessary, or that it hints needs to be assigned before the call to getGridCoverageFactory?

Good eyes! It appears the GeoPackageReader is intentionally using the "defaultHints" provided in the base class. The rationale for this is unknown.

pdavidc · 2017-07-28T21:56:22Z

worldwind-gt-geopkg/src/main/java/gov/nasa/worldwind/geopkg/mosaic/GeoPackageReader.java

+                // TODO: compute the gridRange in the GeoPackage class
+                List<TileMatrix> matricies = tileset.getTileMatricies();
+                TileMatrix matrix = matricies.get(matricies.size() - 1);
+                int maxZoomLevel = matrix.getZoomLevel();


There are two aspects of the GeoPackage spec that could be problematic here:

GeoPackage does not stipulate that tile matrices are ordered, which could invalidate the assumption that the last TileMatrix represents the maximum zoom level. Does the method TileEntry.getTileMatrices provide this guarantee?

GeoPackage allows the definition of tile matrices that have no corresponding tile data in the file. For example, a GeoPackage could define 17 logical levels of tile matrices, yet provide tile data for only levels 5-10. We have test files that do this. In WorldWind Android, I queried the GeoPackage to identify the TileMatrix with the largest zoom level that also had at least one corresponding tile in the tile table.

Re: 1. The GeoPackage class retrieves and assembles its tile matrices in ascending zoom level order.
Re: 2. The query behind the getTileBound method is on "coverage tiles" table, not the tile_matrix table.

To clarify, "coverage tiles table" refers to GeoPackage tile pyramid user data tables?

Yes, that is correct.

pdavidc · 2017-07-28T21:59:47Z

worldwind-gt-geopkg/src/main/java/gov/nasa/worldwind/geopkg/mosaic/GeoPackageReader.java

+                GridEnvelope2D gridRange = new GridEnvelope2D(new Rectangle(
+                        numCols * matrix.getTileWidth(),
+                        numRows * matrix.getTileHeight()));
+


The conversion to GridEnvelope2D appears to lose information. This retains the tile count in each dimension, but drops which row and column the envelope begins at. Have I missed something here?

The conversion is storing the height and width in pixels of the highest resolution level.

It seems odd that the Rectangle's upper left corner would be set to 0, 0. Are you certain that getOriginalGridRange, and any other use of this GridEnvelope2D, will only inspect its dimensions?

I'm been looking into it since your original comment. So far nearly all instances have been on the span, but its a large domain to inspect. I cannot identify an alternative approach to manifesting this data, nor can I propose candidate values for a top/left in this context other than 0,0.

It appears that the domain is logical tile matrix pixels. Given that, would minCol * matrix.getTileWidth() and minRow * matrix.getTileHeight() represent the upper left x and y, respectively?

On second thought, the low/high could be the pixels in the grid. 2^21 * 256 fits in an integer.

zglueck

@emxsys many of the details of the context of this pull request are out of the scope of my Geoserver knowledge :) I focused on the zoom level determination and found no issues in your approach. My spreadsheet backed testing indicated the closest level + 1 would be returned for a given scale denominator.

… and height.

Overriding findMaxZoomAuto to return the zoom level closest to the hi…

50c3d12

…ghest resolution coverage in the request. - Re: issue #75

emxsys added this to the WWSK v0.3.1 milestone Jul 27, 2017

emxsys requested a review from pdavidc July 27, 2017 15:13

ghost assigned emxsys Jul 27, 2017

ghost added the needs review label Jul 27, 2017

pdavidc reviewed Jul 27, 2017

View reviewed changes

emxsys added 2 commits July 28, 2017 14:07

Changed getOriginalGridRange to return the actual range (width, heigh…

21f3b15

…t) of the tiles in the GeoPackage. - Was returning the grid range of the entire grid level. - Added supporting code to compute the grid range. - Refactoring is needed. See TODO statements.

Changed findMaxZoomAuto to compute the scale from the grid range prov…

c6c3adc

…ided by the GridCoverage2DReader. - Provides access to getOriginalGridRange for obtaining the width/height of a GeoPackage.

emxsys requested review from zglueck and Beak-man July 28, 2017 21:15

emxsys mentioned this pull request Jul 28, 2017

Refactor the computation of the GeoPackage's originalGridRange #83

Open

pdavidc reviewed Jul 28, 2017

View reviewed changes

zglueck reviewed Jul 28, 2017

View reviewed changes

Setting the gridOriginalRange x and y values in addition to the width…

9d6d16e

… and height.

emxsys merged commit 35a0cc0 into hotfix/v0.3.1 Jul 29, 2017

ghost removed the needs review label Jul 29, 2017

emxsys deleted the fix/#75-geopackage_export_fidelity branch July 29, 2017 03:01

emxsys restored the fix/#75-geopackage_export_fidelity branch July 29, 2017 03:15

emxsys mentioned this pull request Jul 29, 2017

Release WWSK v0.3.1 Hot Fix #76

Closed

11 tasks

emxsys deleted the fix/#75-geopackage_export_fidelity branch July 29, 2017 04:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Autodetect the max zoom level based on the highest resolution coverage #79

Autodetect the max zoom level based on the highest resolution coverage #79

emxsys commented Jul 27, 2017

emxsys commented Jul 27, 2017

pdavidc Jul 27, 2017

emxsys Jul 27, 2017

emxsys commented Jul 28, 2017

emxsys commented Jul 28, 2017

pdavidc left a comment

pdavidc Jul 28, 2017

emxsys Jul 28, 2017

pdavidc Jul 28, 2017

emxsys Jul 28, 2017

pdavidc Jul 28, 2017

emxsys Jul 28, 2017

pdavidc Jul 28, 2017

emxsys Jul 28, 2017

pdavidc Jul 28, 2017

emxsys Jul 28, 2017

pdavidc Jul 28, 2017

emxsys Jul 28, 2017 •

edited

Loading

zglueck left a comment

Autodetect the max zoom level based on the highest resolution coverage #79

Autodetect the max zoom level based on the highest resolution coverage #79

Conversation

emxsys commented Jul 27, 2017

emxsys commented Jul 27, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emxsys commented Jul 28, 2017

Problem

Options/Ideas

emxsys commented Jul 28, 2017

pdavidc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emxsys Jul 28, 2017 • edited Loading

Choose a reason for hiding this comment

zglueck left a comment

Choose a reason for hiding this comment

emxsys Jul 28, 2017 •

edited

Loading