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

2016-02-20 Thread Chris Reudenbach
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 
>
> 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" 
>  > 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
>  > 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.
>
>   

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

2016-02-19 Thread chris english
Dominik,
There's mention of grass not working on osx 10.11 and a work around
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" 
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 <
> englishchristoph...@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 <
>> englishchristoph...@gmail.com> wrote:
>>
>>> Dominik,
>>>
>>> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>>>  vals <- 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.schnei...@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@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo

>>>
>>>
>>
>

[[alternative HTML version deleted]]


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

2016-02-19 Thread Dominik Schneider
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 <
englishchristoph...@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 <
> englishchristoph...@gmail.com> wrote:
>
>> Dominik,
>>
>> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>>  vals <- 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.schnei...@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@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>>
>

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


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

2016-02-19 Thread chris english
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 <
englishchristoph...@gmail.com> wrote:

> Dominik,
>
> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>  vals <- 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.schnei...@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@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


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

2016-02-19 Thread Chris Reudenbach
Dominik,

If you want to deal with bigger data sets in a fast and more flexible way I 
strongly suggest to use GRASS7. Rgrass7 provides a very good "r-ish" wrapper to 
use it from R. If You are interested i 'll post a typical setup and example for 
your question. Please note you need obligatory a GRASS 7 installation on your 
system.

Cheers Chris 


Am 19. Februar 2016 16:55:32 MEZ, schrieb Dominik Schneider 
:
>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 <
>englishchristoph...@gmail.com> wrote:
>
>> Dominik,
>>
>> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>>  vals <- 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.schnei...@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@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>>
>
>   [[alternative HTML version deleted]]
>
>___
>R-sig-Geo mailing list
>R-sig-Geo@r-project.org
>https://stat.ethz.ch/mailman/listinfo/r-sig-geo

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo