Open ediebold opened 6 years ago
Sorry to spam you, but @markerikson, you seemed pretty knowledgeable about this stuff.
Taking your original suggestion of using gdaladdo to make overviews worked really well, and I'm just looking for a way to make it a bit more automatic, rather than the trial-and error process I do now (which is create overviews, if it crashes, create some more, etc.)
Afraid I haven't gotten that far yet. I know that I've seen examples of the math for calculating zoom levels based on resolution per pixel, but it's been in various copies of gdal2mbtiles
and such.
I can say that based on source datasets I've been experimenting with, this seems to be the progression:
Hmm, I'm now thinking it might be better not to worry about the zoom level at all, and simply figure out a formula based on the number of pixels in the base image and a memory usage goal (I don't want to use file size since I'm often dealing with VRT files).
Basically, by estimating how many pixels I can safely load while staying under the memory goal, I can figure out how many overviews would be needed to stay under that amount even when the whole image is loaded.
I am using QGIS with Tile Map Scale Plugin, which is configurable to use and view TMS zoom-levels. BTW, i am using it also for testing gdal_addo zoom level parameters.
TMS Plugin link: https://plugins.qgis.org/plugins/TileMapScaleLevels/
Hi, I have added a new "Overviews" option to experiment, It works here with input tiff files.
Wow, thanks @ahuarte47. The overview building seems to work well.
My only issue is that the 5 inbuilt levels don't totally fix the issue. On my dataset, with no overviews, I get tiles from levels 7-16. With 5 overviews (of 2, 4, 8, 16, and 32) I get tiles from levels 3-16.
Personally I find this weird, since zoom level 6 is where the entire image is in a single tile, so I don't know why more memory is required after this point. It feels to me like there is a bug in the memory allocation or overview selection at these lower zoom levels. Since I assume overview selection is being done by GDAL, I understand this may not really be fixable.
The quickest solution may be to simply add an argument allowing users to specify how many overviews they want. e.g. If I use "-O 3", it generates overviews using the values 2, 4 and 8. If I use "-O 5", it generates 2, 4, 8, 16 and 32. That way I can just feed it the result of the script I'm making which calculates how many overviews are needed based on pixel size and a memory goal.
I agree Elliot, it is a great idea this new parameter, I will add it ASAP.
Thanks @ahuarte47.
I actually looked into the crashing issue a little myself today. My C++ is pretty poor, so it was slow going, but I believe I’ve found part of the problem- the getOverviewDataset function in GDALTiler.cpp doesn’t account for the tile’s zoom level. Even for the base tiles, it seems to load overviews. Not sure if this is what’s causing the issue, but it’s certainly a bug, since you’d lose resolution on lower layers.
Hi Guys,
I am still having the issue displaying .terrain files in my Cesium. I am also using ctb-tile.exe to generate my custom terrain files. But the console in chrome always show me the same error -> #59
Can anyone help?
Many thanks.
Is there currently a way to see what zoom level ctb-tile will create by default? For example, I have a raster which receives tiles for zoom levels 0-16, and another which gets 0-14, when I don't specify the start and end zoom. I was hoping to find a command that would let me get the "16" and "14" without actually running the tiler and inspecting the files.
This would be useful to allow for automatic overview creation using gdaladdo in order to prevent issues #28 and #37
At the moment, the best solution I know of is to inspect the layers.json produced in @ahuarte47's pull request, but I was wondering if there's anything better.