There's a project called Mapterhorn (https://github.com/mapterhorn/mapterhorn) which combines multiple sources of elevation data to produce high quality, high resolution terrain models. Some of this data comes from LIDAR scanning at the sub-1-metre level, according to https://mapterhorn.com/, combined with lower resolution data for other areas.
Currently GpsPrune uses two sources of elevation data, and they're used to lookup elevations for a track's points and also to build terrain models (draped with map imagery) for the 3d visuals. So currently, GpsPrune downloads SRTM1 files if it can (subject to user registration) and otherwise falls back to the lower-resolution SRTM3. And these files are stored locally in the tile cache.
The idea here is to incorporate Mapterhorn as an optional, additional source of data, which I assume should have the highest priority if available. For this, each user would have to separately get a CLI tool called pmtiles which can download the data from mapterhorn, and this would store a single .pmtiles file in the tile cache. This file can contain one zoom level or multiple levels, and might be constrained by a bbox for just the part of the World of interest.
Once this file is in the cache, then GpsPrune can use it as a data source, but it's not yet clear what GpsPrune's strategy should be:
- Should GpsPrune look for any
.pmtiles files in the cache and go through them all in sequence? Or just look in a specific file, configured in the settings?
- What should GpsPrune do if an altitude for a point is requested but it's not covered by any Mapterhorn file? It won't be able to download them itself (I guess, because it doesn't have the download tool), so should it silently fall back to SRTM1 (if configured) or SRTM3? Or should it just fail, coaxing the user to get more Mapterhorn data?
- If Mapterhorn data is supported, does any user still require SRTM data at all? I'm guessing that there are still users who appreciate the simplicity of SRTM and don't want to figure out how to use
pmtiles. And I'm guessing that there are still users who want to use the low-res SRTM3 without having to register for SRTM1. So would support for all three sources still be necessary?
On the one hand, it would be nice if altitude lookup and 3d views are just "click it and it's done", but on the other hand, it needs to be clear what has happened and where the data came from. Thoughts?
There's a project called Mapterhorn (https://github.com/mapterhorn/mapterhorn) which combines multiple sources of elevation data to produce high quality, high resolution terrain models. Some of this data comes from LIDAR scanning at the sub-1-metre level, according to https://mapterhorn.com/, combined with lower resolution data for other areas.
Currently GpsPrune uses two sources of elevation data, and they're used to lookup elevations for a track's points and also to build terrain models (draped with map imagery) for the 3d visuals. So currently, GpsPrune downloads SRTM1 files if it can (subject to user registration) and otherwise falls back to the lower-resolution SRTM3. And these files are stored locally in the tile cache.
The idea here is to incorporate Mapterhorn as an optional, additional source of data, which I assume should have the highest priority if available. For this, each user would have to separately get a CLI tool called
pmtileswhich can download the data from mapterhorn, and this would store a single.pmtilesfile in the tile cache. This file can contain one zoom level or multiple levels, and might be constrained by abboxfor just the part of the World of interest.Once this file is in the cache, then GpsPrune can use it as a data source, but it's not yet clear what GpsPrune's strategy should be:
.pmtilesfiles in the cache and go through them all in sequence? Or just look in a specific file, configured in the settings?pmtiles. And I'm guessing that there are still users who want to use the low-res SRTM3 without having to register for SRTM1. So would support for all three sources still be necessary?On the one hand, it would be nice if altitude lookup and 3d views are just "click it and it's done", but on the other hand, it needs to be clear what has happened and where the data came from. Thoughts?