You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
✅ 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
❌ VRT restrictions (no mixed projections)
The text was updated successfully, but these errors were encountered:
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]:
The text was updated successfully, but these errors were encountered: