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
Hi, so I don't know if it's intentional, but I couldn't find any documentations on this.
I recently found out that the tool ElevationAboveStreamEuclidean assumes all non zero cells are streams, and the cells with value of zero are the cells we need the elevation information from. And the source code on the file doesn't check for nodata on the dem.
Since the variable for streams is named input, it was a bit confusing, so I wanted to ask if it was intentional.
If it's intentional then we may have to check for nodata in the dem also as a condition for passing nodata in the output dem since the code doesn't do that as far as I understood.
If it wasn't meant to be, I tried to modify it slightly and saw that we can ignore the nodata for streams and only use the nodata from dem as the condition for output cells being nodata.
The reason I think the nodata for streams should be ignored is because the tool to generate the streams raster: ExtractStreams as well as StreamOrder tools gives a raster where all the cells except for the stream cells are no-data, so running ElevationAboveStreamEuclidean directly on that raster gives us useless raster with only zero elevation in the streams cells.
I also tried to see if I could do modifications in the tool ElevationAboveStream, but it turned out to be even more complex, so I am yet unable to do it.
If I'm on a right track I can make a pull request. And add more edits to fine tune it as required.
The text was updated successfully, but these errors were encountered:
Hi, so I don't know if it's intentional, but I couldn't find any documentations on this.
I recently found out that the tool
ElevationAboveStreamEuclidean
assumes all non zero cells are streams, and the cells with value of zero are the cells we need the elevation information from. And the source code on the file doesn't check fornodata
on the dem.Since the variable for streams is named input, it was a bit confusing, so I wanted to ask if it was intentional.
If it's intentional then we may have to check for nodata in the dem also as a condition for passing nodata in the output dem since the code doesn't do that as far as I understood.
If it wasn't meant to be, I tried to modify it slightly and saw that we can ignore the nodata for streams and only use the nodata from dem as the condition for output cells being nodata.
Here's my commit in my fork with a slight change:
Atreyagaurav@d27a269
The reason I think the nodata for streams should be ignored is because the tool to generate the streams raster:
ExtractStreams
as well asStreamOrder
tools gives a raster where all the cells except for the stream cells are no-data, so runningElevationAboveStreamEuclidean
directly on that raster gives us useless raster with only zero elevation in the streams cells.I also tried to see if I could do modifications in the tool
ElevationAboveStream
, but it turned out to be even more complex, so I am yet unable to do it.If I'm on a right track I can make a pull request. And add more edits to fine tune it as required.
The text was updated successfully, but these errors were encountered: