✅ The tool would be useful for other projects like gpxz
❌ More work than a utility function in opentopodata
❌ It's pretty hacky (might have issues with e.g., filesystem paths)
❌ Slowest response time solution (gdal still has to read 2 or 3 VRTs, and do dozens of bounds comparisons)
❌ VRT restrictions (no mixed projections)
Parse VRTs in opentopodata (detect when a dataset contains a single vrt file; manually parse it on startup; use that to build a spatial index or honestly just a list of bounds would be faster than gdal)
✅ Transparent for user
✅ Can fallback to regular (slow) mode if any issues are found.
✅ Fast startup and response time
❌ Parsing a VRT might be more complicated than I'm imagining
Gdal is slow at reading VRTs with lots of files.
Unfortunately, using a VRT file is the only way opentopodata supports datasets without SRTM-style file naming, which is a bad experience for users.
Some options [of things to do for datasets which have more than one file and no SRTM style filenames]: