Forum

Author Topic: cloud-optimized geotiff export, multiple view options like gdal2tiles  (Read 2194 times)

andyroo

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
This is a 2-part feature request:

1) - to add the ability to output Cloud-optimized geotiffs (COGs) in Export Orthomosaic/Tiff/Export TIF/JPG/PNG... and Export DEM/Export TIF/BIL/XYZ...
2) - to add/combine tiled export options to be able to produce one set of tiles (and associated template html & kml) that can be used with multiple viewing options including KML Superoverlay, leaflet, openlayers, google maps, and other tile map services.

Currently I do this with gdal, but it requires multiple passes and is MUCH slower than metashape's efficient raster outputs. We are shifting to cloud-optimized geotif format for DEMs and orthos and starting to use tiled datasets more for serving ortho products to end users, so exporting a temporary raster or raster tiles that I postprocess into something else using slow tools is starting to become a significantly inefficient part of my workflow.

Right now I export TIFFs in metashape either as a single tiff or tiles, then use gdal_translate -of COG to generate COGs (slow), gdalbuildvrt and gdalwarp to make VRTs in EPSG:4326 (fast), and gdal_translate -of KMLSUPEROVERLAY -co FORMAT=AUTO (verrrry sloow) or gdal2tiles -k -processes=[NumCores] (fast but sometimes buggy with gdalwarp generating a LOT of empty tiles) to make the KML superoverlay.

gdal2tiles is nice because it automagically creates viewers for leaflet, openlayers, google maps, and kml (with the -k option). Also it uses all cores for building the KML Superoverlay where gdal_translate doesn't. But gdal_translate supports hybrid JPG and PNG (for edge transparency) tiles. If I could do all of this within metashape, I would jump for joy.

I would love to be able to do these things within Metashape in the export dialog/API. Especially the part where I can create the KML superoverlay not in one giant zip but in a folder heirarchy, and where I can use the same tiles for KML/Google Maps/OpenLayers/Leaflet - lots of flexibility there. If that also generated a VRT or something I could generate a VRT from (point gdal at a product recognized as a raster with gdal) - then I could use those tiles for my COG even if that feature wasn't implemented and it would be much more streamlined.

[edit] - the "-co FORMAT=auto" option with gdal_translate is nice for optimizing size of KML layers, but I'm not sure how it would work with sharing multiple tiles with tile services - I guess probably not well, so maybe that wouldn't make sense to do..

Also adding the KML superoverlay with network links as an option instead of KMZ would be nice because then the whole tile heirarchy could be more easily moved to online services.

Andy

« Last Edit: December 11, 2020, 11:19:07 PM by andyroo »