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 <[email protected]>: > 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 > <[email protected]>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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
