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

Daniel Becker danielbecker82 at gmail.com
Mon Mar 31 00:08:29 PDT 2014


Hi and thanks for your hints and sorry for answering that late,

i didn't run into the memory-problem with a value of 10% until now, but
that way i can't guarantee that it works on even higher pixel numbers.
The problem is caused by the exp() function, maybe it isn't even wrong, but
now i can filter the slopes before as Juan Carlos suggested.

I still have to try how to adress the infinite values, maybe just to set
them to nodata, but there just opened another thread concerning this.

I will will see if there is time to do the example but for now i have to
complete some other assignments.




2014-03-24 11:08 GMT+01:00 Johannes Radinger <johannesradinger at gmail.com>:

> 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/20140331/7a7a3ccf/attachment-0001.html>


More information about the grass-user mailing list