Add identifyflats

[Teschl]

The basic implementation should be not much different from fillsinks, but the output array is made up of int32_tand not float. But instead of just one, there needs to be two (three?) instances of GridObjectreturned.

• flats
• sills
• presills (is that the same as CLOSED in matlab? @wkearn )

These have to be generated from the output matrix.

Depending on if we want to add an argument that decides which of these will get returned, we can decide between something that look roughly like one of those:

1. flats, sills, presills = dem.identifyflats() alternatively result = dem.idenifyflats() where result = (flats, sills, presills)

2. flats= dem.identifyflats(output="flats"), flats, sills = dem.identifyflats(output=["flats", "sills"]) and so on.

Maybe both at the same time, with 1. being the standard would work too.

[wkearn]

• presills (is that the same as CLOSED in matlab? @wkearn )

It is not the same. presills are pixels that are flats, but they border a sill pixel. MATLAB TopoToolbox computes these separately when constructing the FLOWobj, but it is easy enough to identify them when we are scanning over the data in identifyflats. The libtopotoolbox identifyflats function doesn't identify the CLOSED pixels yet -- though it could. I would probably return them with bit 3 set, so that output[pixel] & 8 would be nonzero in that case.

One question I have about this for @wschwanghart: I implemented identifyflats in libtopotoolbox because we need it for flow routing. Is it something that users need to call outside of that context? If so, how do they use the outputs? If not, it might be better just to have identifyflats return the int32 array so we can use it later in the flow routing algorithm.

I am imagining, by the way, that once we get all the basic flow routing stuff implemented in libtopotoolbox (TopoToolbox/libtopotoolbox#5), that the equivalent to the FLOWobj constructor in Python will handle running all of the functions.

class FlowObject():
    def __init__(self,dem):
        filled_dem = dem.fillsinks()
        flats = filled_dem.identifyflats()
        costs = compute_costs(flats,filled_dem,dem)
        D = graydist(costs,flats)
        flow_directions = dem.steepestdescent(flats,D)
        self.edge_list = flow_directions.tsort()

Or something like that. Python handles all the intermediate array allocations and necessary data type conversions, and libtopotoolbox runs the computations. So I think we do need an identifyflats function in pytopotoolbox. Whether it is just for internal use in the library or whether users should be able to call it is the question.

[wschwanghart]

identifyflats is used in FLOWobj, but it is also a GRIDobj function which may be needed in some instances. For example, if DEMs contains lakes whose lake level is represented by a single elevation value, I have used it a lot to identify lakes. Hence, it'll be good if the function is more generally available.

Am Do., 16. Mai 2024 um 18:08 Uhr schrieb William Kearney < @.***>:

• presills (is that the same as CLOSED in matlab? @wkearn https://github.com/wkearn )

It is not the same. presills are pixels that are flats, but they border a sill pixel. MATLAB TopoToolbox computes these separately when constructing the FLOWobj, but it is easy enough to identify them when we are scanning over the data in identifyflats. The libtopotoolbox identifyflats function doesn't identify the CLOSED pixels yet -- though it could. I would probably return them with bit 3 set, so that output[pixel] & 8 would be nonzero in that case.

One question I have about this for @wschwanghart https://github.com/wschwanghart: I implemented identifyflats in libtopotoolbox because we need it for flow routing. Is it something that users need to call outside of that context? If so, how do they use the outputs? If not, it might be better just to have identifyflats return the int32 array so we can use it later in the flow routing algorithm.

I am imagining, by the way, that once we get all the basic flow routing stuff implemented in libtopotoolbox (TopoToolbox/libtopotoolbox#5 https://github.com/TopoToolbox/libtopotoolbox/issues/5), that the equivalent to the FLOWobj constructor in Python will handle running all of the functions.

class FlowObject(): def init(self,dem): filled_dem = dem.fillsinks() flats = filled_dem.identifyflats() costs = compute_costs(flats,filled_dem,dem) D = graydist(costs,flats) flow_directions = dem.steepestdescent(flats,D) self.edge_list = flow_directions.tsort()

Or something like that. Python handles all the intermediate array allocations and necessary data type conversions, and libtopotoolbox runs the computations. So I think we do need an identifyflats function in pytopotoolbox. Whether it is just for internal use in the library or whether users should be able to call it is the question.

— Reply to this email directly, view it on GitHub https://github.com/TopoToolbox/pytopotoolbox/issues/22#issuecomment-2115644166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4RU3CXBBITSAGY4HSUUCDZCTKWXAVCNFSM6AAAAABH2NPD46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJVGY2DIMJWGY . You are receiving this because you were mentioned.Message ID: @.***>