Discrepancies in flow routing between libtopotoolbox and TopoToolbox v2
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start in src/flow_routing.c, especially the unused compute_flowdirection_TT2 function, and compare its results with TopoToolbox v2 on the Big Tujunga DEM example. Investigate the differing treatment of flats and boundary outlets, then verify drainage basin results against the MATLAB workflow. Done means the discrepancies are explained or corrected before merging #121.
Written by the indexing model from the issue text.
Description
I noted in #72
There are differences between the two on flat regions that have to do with how the auxiliary topography is treated. TT2 itself computes different flow directions over flats with its MEX implementation and the default MATLAB implementation. The flow directions of the libtopotoolbox implementation seem more similar to the MATLAB implementation than to the MEX version. There is an unused function in src/flow_routing.c, compute_flowdirection_TT2, which attempts to more directly copy the MEX implementation. However, using compute_flowdirection_TT2 still matches the MATLAB implementation better than it matches the MEX implementation. I am open to exploring these discrepancies more, but I would like to have something that we can start building from.
The discrepancies I noticed when testing #72 seemed quite minor and limited to the flats, but these differences get amplified when computing the drainage basins from the flow routing information using #121.
Here are two maps of drainage basins on the Big Tujunga DEM included with TopoToolbox v2. The left one is computed with
DEM = GRIDobj("DEMdata/srtm_bigtujunga30m_utm11.tif");
FD = FLOWobj(DEM);
L = drainagebasins(FD);
while the right one is computed using libtopotoolbox's flow routing.
It may be hard to tell, but among other things, there are twice as many basins in the libtopotoolbox version than in the TopoToolbox v2 version.
Most or maybe all of those extra basins are on the boundary, which makes me think that in addition to having problems routing over flats, we might also not be identifying outlets on the boundary of the DEM correctly. I didn't notice those earlier because I was primarily looking at maps of flow accumulation, and these small basins have very little flow accumulation.
I would like to figure out what is going on here before merging #121.
- Dominant language
- C
- Stars
- 2
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from TopoToolbox/libtopotoolbox
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
TopoToolbox/libtopotoolbox#236 ·
-
`dbentropy` Open
Difficulty 3/5 1-2 days Newbie friendliness 45/100
TopoToolbox/libtopotoolbox#235 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
TopoToolbox/libtopotoolbox#234 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
TopoToolbox/libtopotoolbox#233 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
TopoToolbox/libtopotoolbox#226 ·
All issues in TopoToolbox/libtopotoolbox
Similar issues
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·
-
bug Self Built Image SNAPSHOT Supported Device target/ramips
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100