Implement libtopotoolbox-based flow routing#156
Merged
Conversation
Resolves TopoToolbox#22 Resolves TopoToolbox#15 This PR finishes implementing a pure libtopotoolbox workflow for flow routing for D8 with the 'carve' preprocessing option. New bindings are implemented for libtopotoolbox's `gwdt`, `flow_routing_d8_carve` and `flow_routing_d8_edgelist`. The latter two functions are combined in a single binding, `tt_flow_routing_d8_carve` because there is no real reason to call them separately. The flow routing interface in libtopotoolbox is expected to change in the near future, so this should minimize the amount of changes needed in the MATLAB code. createAuxiliaryTopo and the FLOWobj constructor now call only libtopotoolbox functions if uselibtt=true. This required a few changes to pass around the correct flats array. libtopotoolbox's `gwdt` expects a 32-bit integer with an encoding of flats, sills and presills, so we need to use libtopotoolbox's identifyflats explicitly to generate this. `flow_routing_d8_carve` also needs the flats array, but it is okay if they are just labels for the flats, so that array is also passed out of createAuxiliaryTopo for use in the FLOWobj constructor. The resulting FLOWobj is not exactly identical to that without libtopotoolbox because of TopoToolbox/libtopotoolbox#122. It is, however, identical to the pytopotoolbox output. The libtopotoolbox implementation is slightly faster than the non-libtopotoolbox one. The snapshot tests are updated to compare the auxiliary topography with a tolerance because libtopotoolbox does not give exactly identical answers as MATLAB for the gray-weighted distance transform. Signed-off-by: William Kearney <william.kearney@uni-potsdam.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #22
Resolves #15
This PR finishes implementing a pure libtopotoolbox workflow for flow routing for D8 with the 'carve' preprocessing option.
New bindings are implemented for libtopotoolbox's
gwdt,flow_routing_d8_carveandflow_routing_d8_edgelist. The latter two functions are combined in a single binding,tt_flow_routing_d8_carvebecause there is no real reason to call them separately. The flow routing interface in libtopotoolbox is expected to change in the near future, so this should minimize the amount of changes needed in the MATLAB code.createAuxiliaryTopo and the FLOWobj constructor now call only libtopotoolbox functions if uselibtt=true. This required a few changes to pass around the correct flats array. libtopotoolbox's
gwdtexpects a 32-bit integer with an encoding of flats, sills and presills, so we need to use libtopotoolbox's identifyflats explicitly to generate this.flow_routing_d8_carvealso needs the flats array, but it is okay if they are just labels for the flats, so that array is also passed out of createAuxiliaryTopo for use in the FLOWobj constructor.The resulting FLOWobj is not exactly identical to that without libtopotoolbox because of TopoToolbox/libtopotoolbox#122. It is, however, identical to the pytopotoolbox output. The libtopotoolbox implementation is slightly faster than the non-libtopotoolbox one.
The snapshot tests are updated to compare the auxiliary topography with a tolerance because libtopotoolbox does not give exactly identical answers as MATLAB for the gray-weighted distance transform.