[R-sig-Geo] calculate "regional" slope

Chris Reudenbach reudenbach at uni-marburg.de
Sat Feb 20 11:14:41 CET 2016


Dominik,

probably I did not catch exactly what  are your issues.

If you want to perform a multiscale analysis of the digital relief you 
should not focus on a 4,8,16 or more neighbors analysis. This would be 
helpful for a least cost path analysis or a single scale but multi 
neighborhood analysis.

If you have problems with your OS and just for getting an idea  you may 
use landserf  the great java tool of Jo Wood http://www.landserf.org/

As far as I understand your question I think a straightforward way would 
be to resample your elevation data in several steps to a coarser 
resolution and derive the information (aspect, watershed) you need. If 
you really want to have the information "on the other side of a 
mountain" You have to define what other side means. Most commonly it 
means something as behind the highest ridge.

But If you want to perform typical hydrological or morphometric analysis 
of the relief I would strongly suggest  the "mature" GIS software 
packages as GRASS7  SAGA GIS 2.12+ or also PCraster. All of them have 
very fast and very  well validated and reliable tools. PCRaster is more 
optimized with respect to the dynamics, while SAGA GIS and GRASS are 
more sophisticated in order to the implemented algorithms. GRASS is most 
optimized with respect to time consuming calculations. So if you "just" 
want to derive the information of the watersheds on different scales you 
can easily use all of these software packages.

There are some more aspects you should mention. If you need to analyze 
let's say 8 tiles of 5 deg SRTM data R is not able to deal with it.  
Even with PCRaster and SAGA you will need a lot of patience.

Maybe a final thought: we are dealing in students courses since some 
years using R and the mentioned GIS packages on all major OS platforms. 
Instead of struggling all the time with not satisfying work arounds for 
OSX you may think about a second partitions with Linux (or even 
Windows).  In the end this will save a lot of time...

If you need any support with one the mentioned topcis please let me know.

cheers Chris R


Am 20.02.2016 um 08:49 schrieb chris english:
>
> Dominik,
> There's mention of grass not working on osx 10.11 and a work around
> grassmac.wikidot.com <http://grassmac.wikidot.com>
>
> I was generally using PCRaster when I was doing watershed/flood 
> re-creations to handle the watershed delineations and the like and 
> don't have an opinion on Grass.
>
> Yeah, that transect was maybe a silly idea but it generalizes surface 
> to line, sort of like Mauana volcano is a cake you've cut in half. And 
> the line is outline.
>
> Chris
>
> On Feb 20, 2016 2:09 AM, "Dominik Schneider" 
> <Dominik.Schneider at colorado.edu 
> <mailto:Dominik.Schneider at colorado.edu>> wrote:
>
>     Chris R,
>     I'd be happy to use grass7 but I can't get it to run on my mac.
>     osx 10.11.3. I have a working qgis from kyngchaos, installed
>     pandoc and cairo on top of that, and disabled sip but the
>     grass7.app just hangs when I try to open it.
>     Chris E,
>     I will try to clarify. Rather than thinking about "side of a
>     mountain", think about "side of a mountain **range**".  The point
>     of calculating a regional slope is that if I am on the west side
>     of a continental divide but on the east side of mountain, the
>     function still returns a value indicating west-facing.  so maybe
>     it's easier to think in meters.   lets assume my DEM is a 500m
>     grid. the slope calculation would give a local value at 500m. This
>     local slope might be east facing, but I am interested in the
>     overall slope across 10km to indicate which way e.g. the watershed
>     is draining.
>     What do you mean with "transect along the z. I.e. roll your dem on
>     it's side."?
>
>
>     On Fri, Feb 19, 2016 at 2:50 PM, chris english
>     <englishchristophera at gmail.com
>     <mailto:englishchristophera at gmail.com>> wrote:
>
>         Dominik,
>         Sorry, I'm still trying to understand your 0.05 to 1.5 degree
>         part of your problem.
>
>         Otherwise, I think you are limited to 8 neighbors as this
>         reflects the documentation as I read it.
>
>         Even Roualt perhaps would be up in arms; but, there's nothing
>         saying you can't do a 16 vs 8 neighbor. You'd have to examine
>         the impacts thereafter, but basically you'd be amending some
>         gdal (probably a line or two of code) for your purposes.
>
>         There are a bunch of things to consider, theoretical and
>         practical; but, why 16 better than 8. And more importantly as
>         you relax, as a matter of rings (in this case), would your
>         analytical result be better? Or potentially have any remainder
>         meaning at all, I.e. I don't know my neighbor's neighbor's
>         neighbor (does that get us out to 16?).
>         And so generalizing beyond some given point might yield not
>         much on a knn influence/likeness basis.
>
>         I think we're first better off dialing back in on what you
>         mean by regional or the 0.5 to 1.5 resolution and then
>         neighborhood size (4, 8,16?).
>
>         Of course another approach to this "what side of the mountain
>         am I on" is to transect along the z. I.e. roll your dem on
>         it's side.
>
>         Anyway, clarify the 0.5/1.5 so I don't go too far astray.
>         Chris
>
>         Thanks for the suggestion Chris. I'm familiar with gdaldem,
>         which raster::terrain is based on, to compute slope from a
>         dem. I now realize that my example isnt a good one because
>         neighbors=8 would achieve what I described. However I actually
>         want some flexibility such that I can specifiy neighbors=16 so
>         that it uses the next "ring" of cells.
>
>         I played around with focal() with weight argument =
>         matrix(rep(c(1,0,0,0,1),5),byrow=T) but couldn't figure out
>         how to solve for a directional slope.
>
>         On Fri, Feb 19, 2016 at 4:09 AM, chris english
>         <englishchristophera at gmail.com
>         <mailto:englishchristophera at gmail.com>> wrote:
>
>             Dominik,
>
>             r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33,
>             ymx=-22)
>              vals <- sample.int <http://sample.int>(1e3,440)
>             r[ ] <- vals
>             #raster::terrain
>             terr_r <- terrain(r, opt='slope', unit='degrees', neighbors=8)
>             Ah, but it appears you want up sampling to 1.5 degrees
>             rather than 0.5 deg.
>             so maybe spatial.tools::projectRaster_rigorous then
>             raster:terrain.
>
>             I'm inclined to end that last so maybe with a question
>             mark. Sorry for an
>             essentially inconclusive response but I was happy to find
>             terrain in any case.
>             Chris
>
>             On Fri, Feb 19, 2016 at 2:59 AM, Dominik Schneider
>             <Dominik.Schneider at colorado.edu
>             <mailto:Dominik.Schneider at colorado.edu>> wrote:
>
>                 I need to calculate slope at different scales. In the
>                 case below, r is a
>                 0.5deg resolution raster and I want the slope for 1.5
>                 deg centered on each
>                 of those 0.5 deg pixels. I'm trying to estimate which
>                 side of mountain
>                 range each pixel is on. So the resulting raster would
>                 have the same number
>                 of pixels as r. The edges can be NA.
>                 any suggestions would be appreciated. Thanks
>
>
>                 r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48,
>                 ymn=-33, ymx=-22)
>                 setValues(r,rnorm(440))
>
>                         [[alternative HTML version deleted]]
>
>                 _______________________________________________
>                 R-sig-Geo mailing list
>                 R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>
>                 https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
>
>


	[[alternative HTML version deleted]]



More information about the R-sig-Geo mailing list