[GRASS-user] Questions concerning r.mapcalc, r.cost and high resolution DEMs

[Juan Carlos Torres]

Daniel

For the first problem I would sugest you to filter high slope values

r.mapcalc h_m=if(slope<70, (0.000166666*(exp(3.5*(abs(tan( 
"slope_in_degree" )+0.05)))))*cellsize, null())

For the second problem, did you try to use a smaller percentage (say 10%)?

best regards

El 24/03/14 10:15, Daniel Becker escribió:
> Hello,
>
> i just joined this mailing list and i hope i'm doing everything right.
>
> I'm in a project where i try to provide an easy way to do a 
> cost-distance analysis, based on a given raster DEM, i did this with 
> ArcGIS earlier but i want more people to be able to use this simple 
> (and faster) approach, but i ran into some problems.
>
>
>
> The workflow looks like this:
>
> DEM -> slope -> r.mapcalc(tobler hiking function) -> cost raster -> 
> r.cost -> cost distance raster -> contours that represent walking 
> distance from a given point.
>
> The function i use in r.mapcalc 
> is: h/m=(0.000166666*(exp(3.5*(abs(tan( "slope_in_degree" 
> )+0.05)))))*cellsize
>
>
> The problems i ran into:
>
>  1. This works with SRTM-data, but if i use a higher resolution DEM
>     (10m), the resulting cost raster contains some infinite values and
>     the r.cost tool doesn't really work anymore
>       * Is there a way to adress "inf" in r.mapcalc? I can just filter
>         everything > 500, but that isn't really satisfying. :)
>       * I don't really know what the underlying problem is, exp()
>         leads to the infinite values, but maybe there is a way to
>         filter those extreme slopes earlier or in the DEM (although
>         the slope raster contains only values <90°)?
>
>  2. ERROR: G_malloc: unable to allocate 524288 bytes of memory at
>     setup.c:64 - happens at 144.024.001 pixels (merged SRTM-DEM of
>     Spain) and above if i don't set "Percent of map to keep in memory"
>     to quite low values of below 20-30%, although neither my RAM nor
>     the harddrive with the .tmp-folder is fully utilized. The problem
>     is: What happens at even higher pixelcounts?
>
>  3. This may be the wrong place for this but: Usability-wise it would
>     be even nicer to use QGIS and its modelbuilder for this approach.
>     The problem is that the parameters for stop_point or
>     stop_coordinate can't stay empty in the QGIS-GUI (which it has to
>     be, since the whole raster should be processed). Maybe there is a
>     way to work around this?
>
> So, i'd be happy if someone could help me. Here is also an example 
> (https://www.dropbox.com/s/i6rsm9v9p7gwfx2/01_isochronen_arroyotobler_ardales.png) of 
> what i'm trying to do, so that it's less abstract. :-)
>
>
> Thanks in advance and have a nice week
>
> Daniel
>
>
> _______________________________________________
> grass-user mailing list
> grass-user en lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user


-- 
=======================================================================
Juan Carlos Torres                      | http://lsi.ugr.es/~jctorres
Laboratorio de Realidad Virtual         | Tlf.: (+34) 645 885 167
Dpto. Lenguajes y Sistemas Informaticos |       (+34) 958 249 307
ETS. Ing. Informatica                   |     interno ugr  71 260
Univ. de Granada                        | FAX: (+34) 958 243 179
=======================================================================

------------ pr?xima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20140324/ee413053/attachment.html>