MVT (directory-style) tiles not being generated when TILING_SCHEME for WorldCRS84Quad is specified
#11749
Comments
|
Feels like the driver awaits only one, square tile at zoom level 0. I do not know how to define matrix sizes of 1x2, 1x3, 1x4 etc with only 3 parameters |
|
Hello @jratike80, thanks for the response. I tried including the $ ogr2ogr --version
GDAL 3.10.1, released 2025/01/08
$ ogr2ogr -f MVT japan_mvt japan.geojson -dsco TILING_SCHEME="EPSG:4326,-180,90,180" -dsco COMPRESS=NO -dsco MAXZOOM=10 -dsco BOUNDS=-180,-90,180,90 -progress --debug ON
GeoJSON: Detected layer of mixed-geometry type features.
GeoJSON: First pass: 31.39 %
GeoJSON: First pass: 62.77 %
GeoJSON: First pass: 94.16 %
GeoJSON: First pass: 100.00 %
GDAL: GDALOpen(japan.geojson, this=0x5c2e2d9b39b0) succeeds as GeoJSON.
GDAL: GDALDriver::Create(MVT,japan_mvt,0,0,0,Unknown,0x5c2e2dd51e00)
MVT: Creating temporary database...
0...10...20...30...40...50...60...70...80...90...100 - done.
GDALVectorTranslate: 47 features written in layer 'japan'
GDAL: GDALClose(japan.geojson, this=0x5c2e2d9b39b0)
MVT: Building output file from temporary database...
GDAL: GDALClose(japan_mvt, this=0x5c2e2dab4670)
GDAL: In GDALDestroy - unloading GDAL shared library.
$ ls japan_mvt/
metadata.json
$ cat japan_mvt/metadata.json
{
"name":"japan_mvt",
"description":"",
"version":2,
"minzoom":0,
"maxzoom":10,
"center":"138.4601795,32.9900357,0",
"bounds":"-180,-90,180,90",
"type":"overlay",
"format":"pbf",
"crs":"EPSG:4326",
"tile_origin_upper_left_x":-180.0,
"tile_origin_upper_left_y":90.0,
"tile_dimension_zoom_0":180.0,
"json":"{\n \"vector_layers\":[\n ],\n \"tilestats\":{\n \"layerCount\":0,\n \"layers\":[\n ]\n }\n}"
} |
|
I also tried to determine which version of GDAL introduced this particular regression, it seems to be version 3.8.0. The version prior to that, 3.7.3, is able to generate tiles with the WorldCRS84Quad tiling scheme. |
|
My colleague @DivyaSreeMunagavalasa and I tested this further - we found out that tiles are generated for features present on the western hemisphere - but not the eastern hemisphere. Most of the data that we deal with is located on the eastern hemisphere, so we didn't realise the issue (I don't know whether this is an issue anymore?) till we tried generating tiles for US states. Using this GeoJSON file with GDAL 3.8.4, tiles are generated as expected. We can confirm that it also works with GDAL 3.10.1. Is there any config option or extra dataset creation option that we can add to fix this? $ ogr2ogr --version
GDAL 3.8.4, released 2024/02/08
$ ogr2ogr -f MVT USA us-states.json -dsco TILING_SCHEME="EPSG:4326,-180,90,180" -dsco COMPRESS=NO -dsco MAXZOOM=10 -progress --debug ON
GeoJSON: Detected layer of mixed-geometry type features.
GeoJSON: First pass: 100.00 %
GDAL: GDALOpen(us-states.json, this=0x596085a77ff0) succeeds as GeoJSON.
GDAL: GDALDriver::Create(MVT,USA,0,0,0,Unknown,0x596085d7dcc0)
MVT: Creating temporary database...
0...10...20...30...40...50...60...70...80...90...100 - done.
GDALVectorTranslate: 52 features written in layer 'us-states'
GDAL: GDALClose(us-states.json, this=0x596085a77ff0)
MVT: Building output file from temporary database...
MVT: 10%...
MVT: 20%...
MVT: 30%...
MVT: 40%...
MVT: 50%...
MVT: 60%...
MVT: 70%...
MVT: 80%...
MVT: 90%...
MVT: 100%...
GDAL: GDALClose(USA, this=0x596085aa55c0)
GDAL: In GDALDestroy - unloading GDAL shared library.
$ ls USA/
0 1 10 2 3 4 5 6 7 8 9 metadata.json
$ cat USA/metadata.json
{
"name":"USA",
"description":"",
"version":2,
"minzoom":0,
"maxzoom":10,
"center":"-127.2658535,44.6405945,0",
"bounds":"-188.9049100,17.9295560,-65.6267970,71.3516330",
"type":"overlay",
"format":"pbf",
"crs":"EPSG:4326",
"tile_origin_upper_left_x":-180.0,
"tile_origin_upper_left_y":90.0,
"tile_dimension_zoom_0":180.0,
"json":"{\n \"vector_layers\":[\n {\n \"id\":\"us-states\",\n \"description\":\"\",\n \"minzoom\":0,\n \"maxzoom\":10,\n \"fields\":{\n \"id\":\"String\",\n \"name\":\"String\",\n \"density\":\"Number\"\n }\n }\n ],\n \"tilestats\":{\n \"layerCount\":1,\n \"layers\":[\n {\n \"layer\":\"us-states\",\n \"count\":52,\n \"geometry\":\"Polygon\",\n \"attributeCount\":3,\n \"attributes\":[\n {\n \"attribute\":\"id\",\n \"count\":52,\n \"type\":\"string\",\n \"values\":[\n \"01\",\n \"02\",\n \"04\",\n \"05\",\n \"06\",\n \"08\",\n \"09\",\n \"10\",\n \"11\",\n \"12\",\n \"13\",\n \"15\",\n \"16\",\n \"17\",\n \"18\",\n \"19\",\n \"20\",\n \"21\",\n \"22\",\n \"23\",\n \"24\",\n \"25\",\n \"26\",\n \"27\",\n \"28\",\n \"29\",\n \"30\",\n \"31\",\n \"32\",\n \"33\",\n \"34\",\n \"35\",\n \"36\",\n \"37\",\n \"38\",\n \"39\",\n \"40\",\n \"41\",\n \"42\",\n \"44\",\n \"45\",\n \"46\",\n \"47\",\n \"48\",\n \"49\",\n \"50\",\n \"51\",\n \"53\",\n \"54\",\n \"55\",\n \"56\",\n \"72\"\n ]\n },\n {\n \"attribute\":\"name\",\n \"count\":52,\n \"type\":\"string\",\n \"values\":[\n \"Alabama\",\n \"Alaska\",\n \"Arizona\",\n \"Arkansas\",\n \"Colorado\",\n \"Delaware\",\n \"Florida\",\n \"Georgia\",\n \"Hawaii\",\n \"Idaho\",\n \"Illinois\",\n \"Indiana\",\n \"Iowa\",\n \"Kansas\",\n \"Kentucky\",\n \"Maine\",\n \"Maryland\",\n \"Michigan\",\n \"Missouri\",\n \"Montana\",\n \"Nebraska\",\n \"Nevada\",\n \"New York\",\n \"Ohio\",\n \"Oklahoma\",\n \"Oregon\",\n \"Texas\",\n \"Utah\",\n \"Vermont\",\n \"Virginia\",\n \"Wyoming\",\n \"California\",\n \"Connecticut\",\n \"District of Columbia\",\n \"Louisiana\",\n \"Massachusetts\",\n \"Minnesota\",\n \"Mississippi\",\n \"New Hampshire\",\n \"New Jersey\",\n \"New Mexico\",\n \"North Carolina\",\n \"North Dakota\",\n \"Pennsylvania\",\n \"Puerto Rico\",\n \"Rhode Island\",\n \"South Carolina\",\n \"South Dakota\",\n \"Tennessee\",\n \"Washington\",\n \"West Virginia\",\n \"Wisconsin\"\n ]\n },\n {\n \"attribute\":\"density\",\n \"count\":51,\n \"type\":\"number\",\n \"values\":[\n 1.264,\n 5.851,\n 6.8579999999999997,\n 9.9160000000000004,\n 17.16,\n 19.149999999999999,\n 23.969999999999999,\n 24.800000000000001,\n 34.299999999999997,\n 35.090000000000003,\n 40.329999999999998,\n 43.039999999999999,\n 49.329999999999998,\n 54.810000000000002,\n 55.219999999999999,\n 56.43,\n 57.049999999999997,\n 63.5,\n 67.140000000000001,\n 67.730000000000004,\n 77.060000000000002,\n 87.260000000000005,\n 88.079999999999998,\n 94.650000000000006,\n 98.069999999999993,\n 102.59999999999999,\n 105.0,\n 105.2,\n 110.0,\n 147.0,\n 155.40000000000001,\n 169.5,\n 173.90000000000001,\n 181.69999999999999,\n 198.19999999999999,\n 204.5,\n 214.09999999999999,\n 231.5,\n 241.69999999999999,\n 281.89999999999998,\n 284.30000000000001,\n 353.39999999999998,\n 412.30000000000001,\n 464.30000000000001,\n 596.29999999999995,\n 739.10000000000002,\n 840.20000000000005,\n 1006.0,\n 1082.0,\n 1189.0,\n 10065.0\n ],\n \"min\":1.264,\n \"max\":10065.0\n }\n ]\n }\n ]\n }\n}"
} |
That is what I meant by "Feels like the driver awaits only one, square tile at zoom level 0." |
|
Fix in #11762. There isn't any workaround I can think of |
|
@jratike80 thanks for explaining your previous comment, I now understand the issue. @rouault thanks for the bug fix. We'll use the latest version that contains the fix. |
What is the bug?
Hello,
metadata.json, but no zoom-level directories are present.Steps to reproduce the issue
Reproducing error with GDAL 3.8.4, 3.10.1
Using GDAL 3.8.4 on Ubuntu, with this GeoJSON file, attempting to generating directory-style MVTs, uncompressed. The tiling scheme values specified corresponds to the TMS WorldCRS84Quad. I get a similar result with GDAL 3.8.5, 3.10.1
Tiles generated as expected with GDAL 3.4.1
This was tested with the
ghcr.io/osgeo/gdal:ubuntu-small-3.4.1Docker image. I can confirm that the tiles generated by this are accurate when plotted on OpenLayers with the WorldCRS84Quad TMS.Versions and provenance
Was able to reproduce on
apt)ghcr.io/osgeo/gdal:ubuntu-small-3.8.5ghcr.io/osgeo/gdal:ubuntu-small-3.10.1Additional context
I'm happy to provide any more information that's required. Thanks!
The text was updated successfully, but these errors were encountered: