[gdal-dev] Fwd: GeoPKG Zoom Level Calculation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Fwd: GeoPKG Zoom Level Calculation

Roarke Gaskill
Hi,

In the GDALGeoPackageDataset class it appears the zoom level in the SetGeoTransform function does not calculate the zoom level correctly.  Also, it is different from the zoom level calculation in CreateCopy function.  The zoom level calculation in the CreateCopy appears to work as I would expect.

The transform I am using to test is:
[-20037508.342789248, 6176.637812966647, 0.0, 19971868.880408563, 0.0, -6177.590116052211]

The CreateCopy zoom level logic produces level 5.  Which is what I would expect.

The SetGeoTransform zoom level logic is not able to identify a zoom level.

Is the SetGeoTransform zoom level calculation logic wrong?

Thanks,
Roarke


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GeoPKG Zoom Level Calculation

Even Rouault-2

On mercredi 13 septembre 2017 15:38:55 CEST Roarke Gaskill wrote:

> Hi,

>

> In the GDALGeoPackageDataset

> <https://github.com/OSGeo/gdal/blob/65dea1c999b6b5f692c945ea074b04cb5e43eca4

> /gdal/ogr/ogrsf_frmts/gpkg/ogrgeopackagedatasource.cpp#L1819> class it

> appears the zoom level in the SetGeoTransform function does not calculate

> the zoom level correctly. Also, it is different from the zoom level

> calculation in CreateCopy

> <https://github.com/OSGeo/gdal/blob/65dea1c999b6b5f692c945ea074b04cb5e43eca4

> /gdal/ogr/ogrsf_frmts/gpkg/ogrgeopackagedatasource.cpp#L4079> function. The

> zoom level calculation in the CreateCopy appears to work as I would expect.

>

> The transform I am using to test is:

> [-20037508.342789248, 6176.637812966647, 0.0, 19971868.880408563, 0.0,

> -6177.590116052211]

>

> The CreateCopy zoom level logic produces level 5. Which is what I would

> expect.

>

> The SetGeoTransform zoom level logic is not able to identify a zoom level.

>

> Is the SetGeoTransform zoom level calculation logic wrong?

 

Roarke,

 

when using SetGeoTransform() and a pre-defined tiling scheme (here I assume you must use GoogleMapsCompatible), the resolution of the geotransform matrix passed to SetGeoTransform() must exactly match the base resolution of the tiling scheme divided by a power of 2

 

>>> 156543.0339280410 / 6176.637812966647

25.344376450147266

 

which is not a power of 2.

 

CreateCopy() in the GPKG implementation with a pre-defined tiling scheme identifies the closest zoom level for your source dataset and then resample it so its resolution matches exactly one of the zoom levels.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GeoPKG Zoom Level Calculation

Roarke Gaskill
Even,

Thanks for your reply.  I get it now.  :)

I am new to gdal in general.  For context, why does CreateCopy() choose the nearest zoom level and not SetGeoTransform()?  As a new user, it seems to me the ZOOM_LEVEL_STRATEGY should apply to both the SetGeoTransform() and CreateCopy().

Thanks again,
Roarke

On Wed, Sep 13, 2017 at 3:50 PM, Even Rouault <[hidden email]> wrote:

On mercredi 13 septembre 2017 15:38:55 CEST Roarke Gaskill wrote:

> Hi,

>

> In the GDALGeoPackageDataset

> <https://github.com/OSGeo/gdal/blob/65dea1c999b6b5f692c945ea074b04cb5e43eca4

> /gdal/ogr/ogrsf_frmts/gpkg/ogrgeopackagedatasource.cpp#L1819> class it

> appears the zoom level in the SetGeoTransform function does not calculate

> the zoom level correctly. Also, it is different from the zoom level

> calculation in CreateCopy

> <https://github.com/OSGeo/gdal/blob/65dea1c999b6b5f692c945ea074b04cb5e43eca4

> /gdal/ogr/ogrsf_frmts/gpkg/ogrgeopackagedatasource.cpp#L4079> function. The

> zoom level calculation in the CreateCopy appears to work as I would expect.

>

> The transform I am using to test is:

> [-20037508.342789248, 6176.637812966647, 0.0, 19971868.880408563, 0.0,

> -6177.590116052211]

>

> The CreateCopy zoom level logic produces level 5. Which is what I would

> expect.

>

> The SetGeoTransform zoom level logic is not able to identify a zoom level.

>

> Is the SetGeoTransform zoom level calculation logic wrong?

 

Roarke,

 

when using SetGeoTransform() and a pre-defined tiling scheme (here I assume you must use GoogleMapsCompatible), the resolution of the geotransform matrix passed to SetGeoTransform() must exactly match the base resolution of the tiling scheme divided by a power of 2

 

>>> 156543.0339280410 / 6176.637812966647

25.344376450147266

 

which is not a power of 2.

 

CreateCopy() in the GPKG implementation with a pre-defined tiling scheme identifies the closest zoom level for your source dataset and then resample it so its resolution matches exactly one of the zoom levels.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
Roarke Gaskill  |Senior Software Engineer


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GeoPKG Zoom Level Calculation

Even Rouault-2

On jeudi 14 septembre 2017 06:26:40 CEST Roarke Gaskill wrote:

> Even,

>

> Thanks for your reply. I get it now. :)

>

> I am new to gdal in general. For context, why does CreateCopy() choose the

> nearest zoom level and not SetGeoTransform()?

 

Most drivers don't handle directly this concept of predefined tiling schemes, and if you want to apply one, you need to use gdalwarp and setting correctly the extent, resolution, etc... The CreateCopy() implementation in the GPKG driver, when tiling scheme is specified, does that automatically for you.

 

But if you do SetGeoTransform() manually and then use the RasterIO() API, no resampling can occur at that level of the driver (like any other drivers), so you have to specify a resolution that respect the constraints of the tiling scheme.

 

> As a new user, it seems to

> me the ZOOM_LEVEL_STRATEGY should apply to both the SetGeoTransform() and

> CreateCopy().

 

I've just added a precision in the doc to mention that ZOOM_LEVEL_STRATEGY only applies to CreateCopy()

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GeoPKG Zoom Level Calculation

Roarke Gaskill
Very cool, thank you for the explanation and the doc update. 



On Thu, Sep 14, 2017 at 6:42 AM, Even Rouault <[hidden email]> wrote:

On jeudi 14 septembre 2017 06:26:40 CEST Roarke Gaskill wrote:

> Even,

>

> Thanks for your reply. I get it now. :)

>

> I am new to gdal in general. For context, why does CreateCopy() choose the

> nearest zoom level and not SetGeoTransform()?

 

Most drivers don't handle directly this concept of predefined tiling schemes, and if you want to apply one, you need to use gdalwarp and setting correctly the extent, resolution, etc... The CreateCopy() implementation in the GPKG driver, when tiling scheme is specified, does that automatically for you.

 

But if you do SetGeoTransform() manually and then use the RasterIO() API, no resampling can occur at that level of the driver (like any other drivers), so you have to specify a resolution that respect the constraints of the tiling scheme.

 

> As a new user, it seems to

> me the ZOOM_LEVEL_STRATEGY should apply to both the SetGeoTransform() and

> CreateCopy().

 

I've just added a precision in the doc to mention that ZOOM_LEVEL_STRATEGY only applies to CreateCopy()

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
Roarke Gaskill  |Senior Software Engineer


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev