Raised by Charlotte Delmas (Issue #16 in https://github.com/CS-SI/BAS)
Description
When "no data" pixels are present, covering some parts of the river, the widths are not accurate.
Reproduce the example
Area: tile T31TCK, around Cahors (France)
Surfwater optical mask: late v1.2 (1.3)
Datetime: 20190312T105841
BAS version: v1.0.3
Python version: 3.12
Output
Around Cahors, BAS gives a width value only for the node 23214200550031, which is 13,75m. In the image, blue pixels represent water, beige pixels represent land (non-water), and transparent pixels represent "no data" areas (Google Maps background)
The width around this point should be approx. 100m
Analysis
It seems that the algorithm already filters cases where the mask does not intersect the reaches line (SWORD v16). However, there may still be an issue when nodes intersect "no data" pixels. A possible solution could be to implement an additional filter to exclude cases where a node is located on a "no data" pixel ?
Raised by Charlotte Delmas (Issue #16 in https://github.com/CS-SI/BAS)
Description
When "no data" pixels are present, covering some parts of the river, the widths are not accurate.
Reproduce the example
Area: tile T31TCK, around Cahors (France)
Surfwater optical mask: late v1.2 (1.3)
Datetime: 20190312T105841
BAS version: v1.0.3
Python version: 3.12
Output
Around Cahors, BAS gives a width value only for the node 23214200550031, which is 13,75m. In the image, blue pixels represent water, beige pixels represent land (non-water), and transparent pixels represent "no data" areas (Google Maps background)
The width around this point should be approx. 100m
Analysis
It seems that the algorithm already filters cases where the mask does not intersect the reaches line (SWORD v16). However, there may still be an issue when nodes intersect "no data" pixels. A possible solution could be to implement an additional filter to exclude cases where a node is located on a "no data" pixel ?