On Sun, Feb 6, 2011 at 12:05 AM, Colin Wren <colindw...@gmail.com> wrote: > Thanks Markus, but unfortunately this module won't work either. The > direction surface of a cost surface analysis can't be re-created by a > hydrology "drainage" steepest descent algorithm. This was why the -d > flag was added (by me under a different name actually :) to r.cost, > r.walk, and r.drain. It makes sense if you think about the elevation > profile of a drainage algorithm path versus a walking algorithm path, > the first makes an exponential curve while the second should make a > linear path (roughly). You don't want to save up the hardest part of > the hike for the end. > You're right. It would be too costly for a hiker to tackle a waterfall.
> Ideally I would need an algorithm which calculates accumulation from a > direction map only. The cost surface itself is not needed. I was > hoping a suite of hydrology modules would first calculate flow > direction and then a second module would calculate flow accumulation > from the direction. Maybe I'll just have to write an addon module for > it if one doesn't exist. > Not that I know. For SFD-like drainage direction (each cell has only one direction to follow), this should not be too hard. A simple FIFO linked list of cells to process and some flag to check if a cell is in the list could do the trick. I think there are also requests for such functionality somewhere in the ml archive. Markus M > > On Sat, Feb 5, 2011 at 11:44 AM, Markus Metz > <markus.metz.gisw...@googlemail.com> wrote: >> On Fri, Feb 4, 2011 at 9:13 PM, Colin Wren <colindw...@gmail.com> wrote: >>> A recent article published in the Journal of Archaeological Science >>> (http://dx.doi.org/10.1016/j.jas.2010.11.006) proposed a method where >>> hydrology models could be used on the product of a cost surface >>> analysis to create a network of paths (instead of just the one made >>> with r.drain -d). The flow accumulation map would represent the number >>> of cells in the map from which a least-cost path would pass through >>> that cell. ie. a flow accumulation of 100 means that 100 cells would >>> have a LCP that would pass through that cell. You could also calculate >>> mobility basins (like a watershed), etc. >>> >>> This is great extension of cost surface analysis except that I don't >>> think it can be done in GRASS right now. r.cost and r.walk produce a >>> cumulative cost surface and a "flow" direction surface, but if I'm >>> right r.terraflow can't take them as inputs because it calculates >>> everything "in-house". >>> >>> I was hoping someone could double-check my logic on this or perhaps >>> suggest an alternative hydrology module(s) which could take the >>> direction surface as an input instead of calculating everything from >>> the elevation surface. >>> >> If the starting points used to generate cumulative cost surfaces are >> not located at the edges of the current region or if they are not >> bordering at least one NULL cell, they will be located in what is >> called in hydrology sinks or depressions because the starting points >> will be surrounded by cells with values higher than the starting >> points. r.terraflow like most other hydrological modules removes these >> sinks, altering the surface which is in this case not desired. >> >> The GRASS modules r.watershed and r.stream.extract do not modify the >> surface and use it as it is. These two modules use a LCP search to >> determine flow directions and accumulate flow and would therefore be >> suitable for the extraction of a network of paths, as long as these >> modules stop routing flow when a starting point is reached. This is >> currently only implemented in r.stream.extract where the rasterized >> starting points which should have a cost of zero in the cumulative >> cost surface can be used to define real depressions (this is also >> possible in r.watershed, but for technical reasons r.watershed will >> not produce the desired results in this case). r.stream extract will >> then use these starting points indicating real depressions or ultimate >> sinks without outflow as starting points for its LCP search. The LCP >> path for a given cell can then be recovered by tracing back the LCP >> search (flow direction in hydrology) to the nearest starting point. A >> direction map is not needed, directions are calculated from the >> (cumulative cost) surface. The calculated directions may differ in >> ambiguous cases, e.g. for >> >> 7 4 7 >> 6 5 6 >> 7 4 7 >> >> the cell with the cumulative cost value 5 can be reached from either >> of the two cells with cumulative cost value 4, i.e. the LCPs from the >> cell with value 5 going through these two cells are both a valid >> solution. The extracted network would represent paths used by at least >> <threshold> cells, e.g. at least 100 cells would have a LCP that would >> pass through a cell that is part of a path network. In >> r.stream.extract, the option d8cut must be zero to enforce SFD. >> >> Mobility basins can then be determined with r.stream.basins. >> >> HTH, >> >> Markus M >> > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
