-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
merge_divide_trees: features in KML and TXT output #26
Comments
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. |
Thank you, and sorry for posing questions that I should be able to figure out myself. I've been able to create a routine that takes 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?! |
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. |
|
I ran the following two commands on each input tile:
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.) |
Thanks! And sorry for not including the commands I ran. I think it was the default value for min. prominence (i.e. 100). |
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? |
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. |
Interesting. I'm using GMT's (https://www.generic-mapping-tools.org/) Thanks for your interest in this! |
You want me to close this? |
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. |
Thanks. I'll keep it open then. I hope to have more time to investigate at some point. |
The contents of merged.txt is identical, but the contents of merged-divide_tree.kml differs when running merge_divide_trees with or without
-f
. Is this expected? Note I'm only checking Peaks in the KML-file.Now lets run again with
-f
:The text was updated successfully, but these errors were encountered: