Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Negative flow path length #300

Closed
ClaRizzo opened this issue Nov 30, 2022 · 8 comments · May be fixed by #314
Closed

Negative flow path length #300

ClaRizzo opened this issue Nov 30, 2022 · 8 comments · May be fixed by #314

Comments

@ClaRizzo
Copy link

  • whitebox version: 2.2.0
  • Python version: 3.10.8

Description

Hi, I’m trying to compute the flow length using the DownslopeFlowpathLength function (both in python and in the QGIS inteface). The tool seems to work, but I have negative lengths as results. Am I doing something wrong? Could you explain what the output represents?
Thank you!

What I Did

wbt.downslope_flowpath_length(flow_dir_catch, flowlength_catch, esri_pntr=True)

Python/QGIS result:

image

Expected result:

image
@jfbourdon
Copy link
Contributor

jfbourdon commented Jan 4, 2023 •
edited

I just tested the same tool using both a Whitebox style and ESRI style flow direction raster and I get the expected results. Could you share the pointer file you are using because I suspect that's where the root of the issue lies. Does this file was generated with ArcMap's Flow Direction tool?

@ClaRizzo
Copy link
Author

ClaRizzo commented Jan 9, 2023 via email •
edited

@jfbourdon
Copy link
Contributor

You will need to post a link directly in your message as a reply made by email won't forward to GitHub any attached file.

@ClaRizzo
Copy link
Author

ClaRizzo commented Jan 9, 2023

Apologies for that.
I have now attached the file.

flowdir_test.zip

@jfbourdon
Copy link
Contributor

Your "outlet pixel" (top row, second column) has a value of 128 instead of 0. As the algorithm doesn't check for this edge case, you get this weird result.

@jfbourdon jfbourdon mentioned this issue Jan 10, 2023
Open
@ClaRizzo
Copy link
Author

Thank you for your answer. Could you please explain more? Do you mean that the outlet always need to have value 0?
We are cutting catchment data from a national raster, so we won't know which cell is the outlet. Would you have any suggestions on how to do it?

@jfbourdon
Copy link
Contributor

It's explained in the D8Pointer documentation:

Notice that grid cells that have no lower neighbours are assigned a flow direction of zero. In a DEM that has been pre-processed to remove all depressions and flat areas, this condition will only occur along the edges of the grid.

So, if your DEM doesn't contain any depression, all cells with a value of zero must then be the outlet of a subbasin.

If you have other more general questions about WBT usage, you can go to WhiteboxTools Google Group.

@ClaRizzo
Copy link
Author

Thank you again for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

DownFlowpathLength: additional check if direction fall into nodata jfbourdon/whitebox-tools
2 participants
@jfbourdon @ClaRizzo