gdal
gdal copied to clipboard
OSGeo
Feature Request for Gdal2Tiles: Support custom Y, X, Z order
Expected behavior and actual behavior.
Description:
For our use case and to improve mapproxy S3 performance, we need to create tiles in reverse tms mode as described in mapproxy documentation here - https://mapproxy.org/docs/1.13.0/caches.html#id13
Expected behavior: Gdal2Tiles will enable user to customize the tiles order for example: -tf yxz (where tf means tiles format)
Actual behavior: Gdal2Tiles don't allow users to specify the a custome tiles format
Steps to reproduce the problem.
run gdal2tiles
What would be the difference to existing option?
--xyz (https://gdal.org/programs/gdal2tiles.html#cmdoption-gdal2tiles-xyz)
Generate XYZ tiles (OSM Slippy Map standard) instead of TMS. In the default mode (TMS), tiles at y=0 are the southern-most tiles, whereas in XYZ mode (used by OGC WMTS too), tiles at y=0 are the northern-most tiles.
I highly doubt you'll see any performance increase or decrease by using layername/x/y/z instead of layername/z/y/x as you'll still have layername as a common prefix. The s3 recommendations mostly apply to monotonously increasing keys (e.g a timestamp) where the bulk of the read requests concern the latest keys - in that case you'll be hitting index rebalancing and the recommendation applies, but that scenario does not apply to slippy tiles.
What would be the difference to existing option?
--xyz (https://gdal.org/programs/gdal2tiles.html#cmdoption-gdal2tiles-xyz) Generate XYZ tiles (OSM Slippy Map standard) instead of TMS. In the default mode (TMS), tiles at y=0 are the southern-most tiles, whereas in XYZ mode (used by OGC WMTS too), tiles at y=0 are the northern-most tiles.
This will only reverse the 'y' to '-y' - i want to reverse the order the tiles are created with (the folder hierarchy)
I highly doubt you'll see any performance increase or decrease by using layername/x/y/z instead of layername/z/y/x as you'll still have layername as a common prefix. The s3 recommendations mostly apply to monotonously increasing keys (e.g a timestamp) where the bulk of the read requests concern the latest keys - in that case you'll be hitting index rebalancing and the recommendation applies, but that scenario does not apply to slippy tiles.
As the issue of formating the tiles to 'y/x/z.format' is defined in mapProxy official docs it can't be lightly discarded, morever it does make sense that the indexing behind would work better if the Z is switched with the Y as Z will describe only the zoom levels (usually 1..18) and the Y can be thousands
defined in mapProxy official docs it can't be lightly discarded,
yes, but from AWS docs themselves: https://aws.amazon.com/premiumsupport/knowledge-center/s3-object-key-naming-pattern/?nc1=h_ls "Because Amazon S3 optimizes its prefixes for request rates, unique key naming patterns are no longer a best practice."
Hi, @rouault as i understand it if the folder structure starts with the 'Y' instead of 'Z' then the partitions themselves will be initially smaller, moreover not all S3 implementations are of Amazon (they might be compatible but not exact) so the naming conventions does matter