The main reason (at the time - over 4 years ago) was: - that there was no write support for mbtiles then (as you no doubt saw in the link you provided)
I just tried gdal_translate on a sample file and see: - that it (seems) to support only 1 zoom level > Warning 6: driver MBTiles does not support creation option ZOOM_LEVEL > Whereas gdal2tiles supports a from/to zoom-levels - creating the lowest level and then building the upper level from that -- gdal_translate only does the first, but stops there Since the main purpose of gdal2tiles is to create a set of tiles - writing the output to a -- tile-directory or -- a tile-database (which mbtiles is) is a choice that should be offered. In this case, the offered code is a full implementation of the mbtiles specification - where as gdal_translate seems to have only a minimal support At the time, the Geopaparazzi Users used gda2tiles heavily - but due to the restrictions of FAT32 on sdcard's was almost impossible to use After the implementation of writing mbtiles directly inside Geopaparazzi was done - the reported problems went down to a near 0 Since the need existed for many to use the Application where no Internet connections exists, with the needed Zoom-Levels, this became a highly used function. There has also been no requests the extend the features offered, so the implementation (which the python version was based upon) seem to fulfill all the needs. For gdal2tiles to create a result that is a single file - is simply easier to employ and use So the short answer would be: - one is a full implementation - that would fulfill all needs - the other a partial implementation - that does not fulfill all needs Mark
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
