[GRASS-user] problems with r.cost

GRASS GRASS user
1

Hi Hamish,

Thanks for getting back to me.

I am using 6.2.1, and g.region -p gives the info:

projection: 1 (UTM)
zone: 10
datum: nad83
ellipsoid: grs80
north: 4269999
south: 4180119
west: 598614
east: 651978
nsres: 3
ewres: 3
rows: 29960
cols: 17788
cells: 532928480

I'm trying to run with the resolution of 3m, but when I change it to 30m,
there isn't a problem. Using much smaller regions doesn't seem to have
this problem. So is the file just too large at too small of a resolution?
I'll try to run Spearfish and let you know.

thanks again,

paul

Paul Haverkamp wrote:
>
> i'm a very new user to grass and am using r.cost in grass6.2. i'm
> trying to run a cost analysis on my raster and having some difficulty.

which version of 6.2? 6.2.0 or 6.2.1?

how big is your region? (g.region -p) Does it happen if you make the
region smaller or adjust the resolution?

can you reproduce it using the Spearfish demo dataset? if so, can you
post instructions with that in the grass bug tracker?

thanks,
Hamish

2

On Wed, 23 May 2007, Paul Haverkamp wrote:

I am using 6.2.1, and g.region -p gives the info:

projection: 1 (UTM)
zone: 10
datum: nad83
ellipsoid: grs80
north: 4269999
south: 4180119
west: 598614
east: 651978
nsres: 3
ewres: 3
rows: 29960
cols: 17788
cells: 532928480

I've very new to all of this, so please forgive what may be a very obvious question, but can someone explain the units for these coordinates? I'm thinking that "north: 4269999" must indicate the distance North of some reference location, perhaps the equator? It this in feet, meters, miles, kilometers, or something else entirely?

- Wayde

3

One thing to try if you haven't already is to recompile grass with large
file support included. I don't know why that's not done automatically but
apparently it isn't.

Another, if region size is really the issue and you are a C programmer or
know one, is to modify the make file of a grass add-on called r.terracost.
It was written as a CS project at Bowdoin at a time when grass was at
version 5.3. With the move to version 6, the make process changed slightly.
The r.terracost files are available at
http://www.bowdoin.edu/~ltoma/research.html

Or you could get grass5.3 and run r.terracost with it.

Regards, Jerry

-----Original Message-----
From: grassuser-bounces@grass.itc.it [mailto:grassuser-bounces@grass.itc.it]
On Behalf Of Paul Haverkamp
Sent: Wednesday, May 23, 2007 12:45 PM
To: Hamish
Cc: grassuser@grass.itc.it
Subject: Re: [GRASS-user] problems with r.cost

Hi Hamish,

Thanks for getting back to me.

I am using 6.2.1, and g.region -p gives the info:

projection: 1 (UTM)
zone: 10
datum: nad83
ellipsoid: grs80
north: 4269999
south: 4180119
west: 598614
east: 651978
nsres: 3
ewres: 3
rows: 29960
cols: 17788
cells: 532928480

I'm trying to run with the resolution of 3m, but when I change it to 30m,
there isn't a problem. Using much smaller regions doesn't seem to have
this problem. So is the file just too large at too small of a resolution?
I'll try to run Spearfish and let you know.

thanks again,

paul

Paul Haverkamp wrote:
>
> i'm a very new user to grass and am using r.cost in grass6.2. i'm
> trying to run a cost analysis on my raster and having some difficulty.

which version of 6.2? 6.2.0 or 6.2.1?

how big is your region? (g.region -p) Does it happen if you make the
region smaller or adjust the resolution?

can you reproduce it using the Spearfish demo dataset? if so, can you
post instructions with that in the grass bug tracker?

thanks,
Hamish

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

4

Wayde Allen wrote:

> I am using 6.2.1, and g.region -p gives the info:
>
> projection: 1 (UTM)
> zone: 10
> datum: nad83
> ellipsoid: grs80
> north: 4269999
> south: 4180119
> west: 598614
> east: 651978
> nsres: 3
> ewres: 3
> rows: 29960
> cols: 17788
> cells: 532928480

I've very new to all of this, so please forgive what may be a very obvious
question, but can someone explain the units for these coordinates? I'm
thinking that "north: 4269999" must indicate the distance North of some
reference location, perhaps the equator? It this in feet, meters, miles,
kilometers, or something else entirely?

In most cases, coordinates are in metres. Some coordinate systems use
feet (normally US survey feet; any countries which historically used
Imperial feet have long since gone metric for cartographic purposes),
but UTM is always in metres.

Sometimes the zero value is meaningful (e.g. a specific parallel or
meridian), sometimes it isn't. Many coordinate systems add a fixed
constant (false easting/northing) to ensure that coordinates are
always positive.

For UTM, the "base" origin is the intersection of the zone's central
meridian (127W for zone 10) with the equator, but a false easting of
500,000m is added. For the southern hemisphere a false northing of
10,000,000m is added.

So, in the above case, the north-west corner (4269999, 598614) is
~4,270 km north of the equator, and ~98.6 km east of the 127W
meridian.

However, the process of mapping an ellipsoid to a plane introduces
distortion, so the coordinates don't exactly correspond to distances.
E.g. the transverse Mercator projection exaggerates north-south
distances as you move further from the central meridian. To
compensate, a scale factor of 0.9996 is applied to northings, so that
the overall scale factor varies from 0.9996 at the central meridian to
~1.0010 at the boundaries.

--
Glynn Clements <glynn@gclements.plus.com>

5

Paul Haverkamp wrote:

> > i'm a very new user to grass and am using r.cost in grass6.2. i'm
> > trying to run a cost analysis on my raster and having some
> > difficulty.

..

I am using 6.2.1, and g.region -p gives the info:

..

north: 4269999
south: 4180119
west: 598614
east: 651978
nsres: 3
ewres: 3
rows: 29960
cols: 17788
cells: 532928480

I'm trying to run with the resolution of 3m, but when I change it to
30m, there isn't a problem. Using much smaller regions doesn't seem
to have this problem. So is the file just too large at too small of a
resolution?

Your region is way too large for r.cost. It should exit with a memory
error, apparently it isn't doing that. (beyond "segment_seek: invalid
argument")

In r.cost try setting percent_memory=10 or so, but it will still take a
long long long time. Try running at 30m resolution to start with.

532928480 cells (533m) would need at least 2gig RAM to run at percent=100.

watch the progress with "top" from the command line. "M" will sort by
memory use, which is a bit more stable way of watching it.

Hamish

6

Wayde Allen wrote:

> projection: 1 (UTM)
> zone: 10
> datum: nad83
> ellipsoid: grs80
> north: 4269999
> south: 4180119
> west: 598614
> east: 651978

..

I've very new to all of this, so please forgive what may be a very
obvious question, but can someone explain the units for these
coordinates? I'm thinking that "north: 4269999" must indicate the
distance North of some reference location, perhaps the equator? It
this in feet, meters, miles, kilometers, or something else entirely?

This is the "UTM Zone 10" projection. It is measured in meters.

To add to Glynn's explanation, see
  http://grass.gdf-hannover.de/wiki/Gis_Concepts
  and "g.proj -p"

Hamish

7

On Wednesday 23 May 2007 05:28, Wayde Allen wrote:

On Wed, 23 May 2007, Paul Haverkamp wrote:
> I am using 6.2.1, and g.region -p gives the info:
>
> projection: 1 (UTM)
> zone: 10
> datum: nad83
> ellipsoid: grs80
> north: 4269999
> south: 4180119
> west: 598614
> east: 651978
> nsres: 3
> ewres: 3
> rows: 29960
> cols: 17788
> cells: 532928480

I've very new to all of this, so please forgive what may be a very obvious
question, but can someone explain the units for these coordinates? I'm
thinking that "north: 4269999" must indicate the distance North of some
reference location, perhaps the equator? It this in feet, meters, miles,
kilometers, or something else entirely?

- Wayde

The UniversalTransverse Mecator (UTM) divides the globe up into 60 "Zones."
Zone 10 takes in the western coast of North America and for those of us who
live and work here, and use UTM coordinates, we recognize a rectangle that
takes in the north-central portion of the Great Valley of California between
about Woodland on the north and Manteca on the south, effectively the
Sacramento - San Joaquin river delta and the valley area surrounding it on
the north, east, and west. It's a pretty big region.

JDougherty

8

Hamish (and all): Paul is working with me on this project, and the system we
are running it on is a 64-bit debian system with plenty of RAM/scratch space
(and the version we are using is the 64-bit grass release) -- why would
memory problems be an issue? We tried lowering the % memory but it doesn't
seem to help...

--j

-----Original Message-----
From: grassuser-bounces@grass.itc.it [mailto:grassuser-bounces@grass.itc.it]
On Behalf Of Hamish
Sent: Wednesday, May 23, 2007 6:51 PM
To: Paul Haverkamp
Cc: grassuser@grass.itc.it
Subject: Re: [GRASS-user] problems with r.cost

Paul Haverkamp wrote:

> > i'm a very new user to grass and am using r.cost in grass6.2. i'm
> > trying to run a cost analysis on my raster and having some
> > difficulty.

..

I am using 6.2.1, and g.region -p gives the info:

..

north: 4269999
south: 4180119
west: 598614
east: 651978
nsres: 3
ewres: 3
rows: 29960
cols: 17788
cells: 532928480

I'm trying to run with the resolution of 3m, but when I change it to
30m, there isn't a problem. Using much smaller regions doesn't seem
to have this problem. So is the file just too large at too small of a
resolution?

Your region is way too large for r.cost. It should exit with a memory
error, apparently it isn't doing that. (beyond "segment_seek: invalid
argument")

In r.cost try setting percent_memory=10 or so, but it will still take a
long long long time. Try running at 30m resolution to start with.

532928480 cells (533m) would need at least 2gig RAM to run at percent=100.

watch the progress with "top" from the command line. "M" will sort by
memory use, which is a bit more stable way of watching it.

Hamish

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

9

Jonathan Greenberg wrote:

Hamish (and all): Paul is working with me on this project, and the
system we are running it on is a 64-bit debian system with plenty of
RAM/scratch space (and the version we are using is the 64-bit grass
release) -- why would memory problems be an issue? We tried lowering
the % memory but it doesn't seem to help...

does it work for a smaller region or coarser resolution? for example try
changing it from 3 to 30m res.

ie can you determine if is it a 64bit computational error or an out-of-
resources error? (does r.cost work for the spearfish DEM on your system?)

I can't answer why memory problems would be an issue, but that doesn't
mean they aren't! Large mem grass is still untested territory in many
places, maybe you have discovered something new.

Did r.terracost work? How does that compare to r.cost? (if it's good,
I'm thinking maybe Laura would allow us to merge it in CVS as a
companion to r.terraflow, or package as a GEM)
Or does that use GRASS 5 sites as starting/end points and need porting?

Hamish