Open lefsky opened 3 months ago
I don't think it's too challenging, I started (naively) but haven't gotten back to it: https://lists.osgeo.org/pipermail/gdal-dev/2024-April/058950.html
I actually feel that gdal2tiles.py is a little bit old-style now and could do with a rewrite (I personally would wish it be "librarified" and be a C++ function), but I'm nowhere near being able to start on that in terms of available skill or time.
There aren't huge numbers of contributors to GDAL and they all have their own priorities and commitments of course. Another factor may be that simply creating a COG GeoTIFF is a better option, certainly that's my first choice for a massive dataset to be hosted online. I see tile creation as an interesting intellectual exercise and way to understand how the API and Python bindings work (I've written my own wrapper with the API in R for example), but unless you have an older program/situation to feed with tiles COG is really all that's needed to serve up imagery efficiently, and way tidier than a hierarchy of files.
It's also pretty easy to loop over levels and tiles in a COG to write them out to files which might give you a workaround.
I've been puzzling over why this hasn't been done yet. Is there some programming challenge I'm not seeing?
I believe that the only challenges are to find some programmer resources, interest, time, and funding.
The history of gdal2tiles began from a Google Summer of code project. https://wiki.osgeo.org/wiki/GDAL2Tiles_SoC_2007 After that the original author has continued the work in other context with good success https://www.klokantech.com/products/.
I think that the original plan "Implemetation of the file format driver will allow to export map raster data into Google Earth, Google Maps and other online viewers from any of applications which use GDAL library" is still what most users want. But of course a wish to deliver other kind of data as tiles is also valid.
Feature description
gdal2tiles is currently limited to byte images, should handle all valid pixel types
Additional context
I've been puzzling over why this hasn't been done yet. Is there some programming challenge I'm not seeing?