CityRiverSpaces / prototyping

Initial prototyping material
Apache License 2.0
0 stars 0 forks source link

Valley boundary delineation #1

Open cforgaci opened 6 months ago

cforgaci commented 6 months ago
cforgaci commented 6 months ago

A stepwise GIS approach for the delineation of river valley bottom within drainage basins using a cost distance accumulation analysis

The cost distance accumulation algorithm described in this paper can be used to delineate the valley bottom.

Steps:

  1. Depressionless raster: eliminate localized peaks and sinks

  2. Conditioned slope raster: replace values of 0 with small positive values

  3. calculate cost distance accumulation within the drainage basin from river center lines

  4. extract the river valley bottom from the cost distance accumulation raster based “on calculating an estimate of the threshold cost distance accumulation that corresponds to the boundary of the river valley bottom using wetland areas that are adjacent to rivers.”

    1. extract wetlands through a spatial analysis of proximity between input wetland and river layers.

    2. filter above zero and max. 500 CDA values

    3. calculate the mean of the resulting values to be used as a threshold CDA for extracting the river valley bottom

  5. Repeat for all drainage basins involved

ArcPy code available upon request: [gasper.sechu@agro.au.dk](https://github.com/orgs/CityRiverSpaces/projects/1/views/gasper.sechu@agro.au.dk)

cforgaci commented 5 months ago

Valley delineation:

Data sources:

cforgaci commented 5 months ago

This is a secondary task under coridor edge delineation. We explore this further while focusing on the corridor edge delineation.

cforgaci commented 5 months ago

@cforgaci checks why wetlands are used in the delineation method.

cforgaci commented 5 months ago

Wetlands adjacent to rivers are used to calculate "an estimate of the threshold cost distance accumulation that corresponds to the boundary of the river valley". Wetland coverage is limited in urban areas and might not be necessary on a the scale of a city.

cforgaci commented 2 months ago

@fnattino at the useR conference I met someone from the GRASS GIS core team who recommended r.geomorphon for our valley delineation task. Let's explore this too. GRASS GIS can be accessed in R via the rgrass package.

cforgaci commented 2 months ago

@fnattino at the useR conference I met someone from the GRASS GIS core team who recommended r.geomorphon for our valley delineation task. Let's explore this too. GRASS GIS can be accessed in R via the rgrass package.

I am hitting several walls with this:

  1. Installation of GRASS GIS has proven to be difficult as I cannot make the environment variables and hence the communicaiton between rgrass and GRASS GIS work. So, I am afraid introducing this dependency is problematic and undesirable.
  2. I checked the output of the r.geomorphon algorithm from GRASS GIS and its SAGA equivalent Geomorphons, but I do not manage to detext the valley. This issue might be due to the local scale of the elevation model and because it is not a DTM.

I would not rule out this approach entirely, but I am less confident in it now. Let's discuss this in our next meeting.

fnattino commented 1 month ago

With #14 , I think we have now understood a clearer understanding on the difference between how the costDist function from the rspatial/terra package works and "the Vermont method", which makes use of the PathDistance tool from ArcGIS (now deprecated and replaced by the Distance Accumulation).

Both determine the minimum accumulative cost from a source (the river bed) to each cell location. However, costDist multiplies the values in the "friction" raster cells by horizontal distances, while the path distance tool multiplies the friction by actual surface distances (as determined from the horizontal distances plus the elevation). Now, when using the terrain slope as friction raster, I would argue that the use of the cost distance tool produces an output that is more physically sound than the path distance tool: the output raster can be really interpreted as accumulated elevation across the path with minimum slope. From what I understand from reference [1] below, the friction employed in the path distance tool should instead reflect other types of impedance (in the example, surface roughness) - the terrain shape is already accounted by the fact that actual surface distances (and not horizontal distances are used).

This resources explain the difference between the cost distance and the path distance as implemented in ArcGIS: [1] https://pro.arcgis.com/en/pro-app/latest/tool-reference/spatial-analyst/understanding-path-distance-analysis.htm [2] https://pro.arcgis.com/en/pro-app/latest/tool-reference/spatial-analyst/cost-distance.htm

fnattino commented 1 month ago

But getting back to the use of cost distances for the delineation of the valley edge for CRiSp:

cforgaci commented 1 week ago

Working with the cost distance approach and the threshold set as in https://hess.copernicus.org/preprints/hess-2020-361/ we approximate the valley edges reasonably well. We still need to test to what extent the resulting valley polygon leads to a correct delienation on the street network.

The downside of this approach is that the cost distance threshold is manually fixed for the entire valley, which means that it cannot account for changes in ridge height along the valley.

If results are good enough, we use this method for now, but in the long term we will consider a different valley detection method that can overcome differences in height along the valley. This will probably work on a smoothed-out raster and should automatically determine the height of the valley.

Replacing the manually set threshdold with this automatic method is also essential for the scalability of delineation, because variation accurs not only along one valley but across cases (different valley depths) as well.