merge_divide_trees: features in KML and TXT output about mountains

[akirmse]

Yes, this is expected. -f deletes the "runoffs", which are intermediate entities that are needed if the output is to be merged further. You can read more about runoffs at https://www.andrewkirmse.com/prominence.

The KML output is mostly for debugging purposes. Maybe I should default to not generating it.

[anbj]

Thank you, and sorry for posing questions that I should be able to figure out myself.
I've read your posts about this, I just need to grasp it.

I've been able to create a routine that takes (x,y,z), resamples and processes the data into a grid that prominence and WinProm can use. Very exciting.

Oh, and one more thing; I just processed a tile, and was very surprised that the highest point in my tile, was not included in the final data set. Need to look at it some more, but do you have any idea if this would be an issue if the input grid contains only negative numbers? This is bathymetry, so all z-values < 0. Since Mt. Everest is the highwat point on the land masses, the prominence is by definition, it's height (I think..). But how do you do this when < 0. What's the datum?!

[akirmse]

Hm, yes, that's true, there's not really a well-defined prominence value for the highest point < 0. For Everest, using the elevation matches intuition as the high point of a land mass, but I don't know what the right answer is for bathymetry.

[anbj]

• Ref. my post above, I'm a bit puzzled.

• Without introducing my own confused musings on this, here's a note.

• I have generated an 'SRTM pseudo tile' based on data from various sources. All is bathymetry, so z < 0. The region is 2E-3E, 72-73N.

• Since the highest peak, based on eyeballing, is missing, I thought it may have something to do with the negative z's.

• I took my original grid and added 4000 to the z-value. 4000 was arbitrarily chosen, just to get all z > 0.

• Here's screenshot of a run with the original grid (z < 0). From the kml-file:
  

• And the resulting txt-file:
  

• And here's a screenshot of a run with the shifted grid (z > 0). From the kml file:
  

• And the resulting txt-file:
  

• If you want to do your own run, I'm attaching the files.
  files.zip

  • N72E002-original.hgt - original file, z < 0.
  • N72E002-shifted.hgt - shifted (+4000) file, z > 0.

[akirmse]

I ran the following two commands on each input tile:

\mountains\code\release\prominence.exe -f SRTM 72 73 2 3 
\mountains\code\release\merge_divide_trees -f output prominence-72x00-002x00-divide_tree_pruned_100.dvt

What I found is similar to what you're seeing. The shifted version has two additional output points. One is the dataset high point, which is expected to be missing in the output for the original tile, because as we discussed, it's not clear what the prominence of that point is when the data is all negative. But the other looks like it may be a bug. I'm investigating.

(Note that since we didn't specify a min prominence, the default value of 100 was used. Also, I ran merge_divide_trees with the -f flag, which removed points around the boundary that don't have sufficient prominence within the tile, but which might if the tile were merged with neighbors. I did that just to reduce the number of points I had to look at.)

[anbj]

Thanks!

And sorry for not including the commands I ran. I think it was the default value for min. prominence (i.e. 100).

[akirmse]

I did some careful debugging and did see a tiny difference in one calculation that I couldn't explain. I did a diff of the two rasters in QGIS and found that most corresponding pixels have a difference of 4000, but a non-trivial number (a few hundred) have a difference of 4001. That might or might not explain the prominence difference, but it does make debugging extremely difficult. Is it possible this is due to floating point discrepancies in the shift you applied?

[akirmse]

It's also possible that QGIS is producing false positives due to floating point rounding.. just wanted to be sure you know that the two rasters are exactly 4000 apart everywhere.

[anbj]

Interesting. I'm using GMT's (https://www.generic-mapping-tools.org/) grdmath to shift the grid, and I don't think this should cause/introduce any floating point discrepancies, but who knows. I'll do some investigation.

Thanks for your interest in this!

[anbj]

You want me to close this?

[akirmse]

Up to you.. I haven't looked at it again. I'd need to know more about how the shift of 4000 was done before investigating further, in case that's what introduced the discrepancy.

[anbj]

Thanks. I'll keep it open then. I hope to have more time to investigate at some point.