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

[Johannes Radinger]

Hi Daniel,

concerning your first point, you could try to run simpler calculations of
your quite nested mapcalc expression, in order
to pin down which cells cause problems at certain levels of calculations.
Eg. just run a simpler mapcalculation like and identify the levels of
calculation and cells that cause your problem:
 simple1=abs(tan( "slope_in_degree" )+0.05)
 simpe2=exp(3.5*(simple1))

Maybe you can also provide a small reproducable example (with the
NorthCaroline Sample Dataset if possible)
/Johannes


On Mon, Mar 24, 2014 at 10:15 AM, Daniel Becker <danielbecker82 at gmail.com>wrote:

> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20140324/7c2c69c8/attachment-0001.html>