Ability to read single terrain file with arbitrary regional extent? about mountains

[akirmse]

The algorithms don't care about physical extent, but of course the data needs to be interpreted correctly to produce latitudes and longitudes at the end. You can see how supported tile formats are implemented here:

https://github.com/akirmse/mountains/blob/master/code/file_format.h
https://github.com/akirmse/mountains/blob/master/code/file_format.cpp

Handling 2 degree tiles instead of 1 degree does not seem very hard. Note that the filenames need to be predictable given a lat/lng (or X/Y in the case of UTM coordinates). And exotic formats like JP2 aren't natively supported; you'd want to use a tool like gdal_translate to first convert it to FLT files (see the README).

[anbj]

Thanks. The tiles are also available as 1 degree tiles. Will look at the code.

[anbj]

I see now that it is the resolution (2 and 1 degree) I’m referring to - not tile extent. Sorry.

[anbj]

I converted a grid to flt, renamed it to GLO30-filename style and specified -f "GLO30".
Complained that Couldn't read tile file: tile/Copernicus_DSM_COG_10_N59_00_E005_00_DEM.flt, got 1266436 samples expecting 8640000. I assume this is because GLO30 format is 2400*3600 cells and prominence is 'hardwired' to expect this amount of cellls/samples per tile (for GLO30).

Wish thinking: converting a grid to flt is easy. Making it the 'right' dimension is more cumbersome. Imagine if prominence could eat any *.flt without caring if it was SRTM, GLO30, etc.

This program is super interesting; I have to find a way to use it on other data. Think of all the mountains below the sea surface.

[akirmse]

GLO30 has strange latitude-dependent resolutions and requires special handling: https://copernicus-dem-30m.s3.amazonaws.com/readme.html

Perhaps you could add a generic tile format that does what you want? I'm on vacation at the moment and can't take a look for a few weeks. Can you send a pointer to the data you're trying to use? Note that FLT has no metadata such as width, height, or number of overlap pixels, which is why the code has to make assumptions.

[anbj]

First, sorry for disturbing your vacation.
I'm kind of using this issue as thinking loud as well.

I'm usually looking at data not being part of a worldwide, tiled datasets (SRTM, GLO30 etc.). It's more like geotiffs of 10-100's of km2, covering arbitrary geographic extent. Again, file formats are easily abstracted away with great tools like gdal_translate, as you've pointed out. I'll look more at it. My dream situation would again be to just give prominence a single file, and don't have to worry about 'tile size', samples, etc.

After some initial problems I discovered that (some of) the scripts need awscli.

Thanks for answering and enjoy your vacation!