Helena, I think grass assumes x,y, and z are all in the same units when it does the slope calculation. At least when I run r.slope.aspect on my lat long file I get junk out but when I project it to utm and then run r.slope.aspect I get numbers that look reasonable.
Jerry
---- Original message ----
Date: Fri, 13 Apr 2007 09:13:26 -0400
From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: [GRASS-dev] ascii export and import, large file problem
To: Gerald Nelson <gnelson@uiuc.edu>
Cc: grass-dev list <grass-dev@grass.itc.it>On Apr 13, 2007, at 8:39 AM, Gerald Nelson wrote:
Helena, I think the issue when I tried this before is that grass
doesn't know that x and y are in degrees while z is in meters. It
either assumes they are the same or uses the zfactor option to
multiply the z value by something to get it into the same units as
x and y.that issue relates to feet - r.slope.aspect converts x,y, or rather
the horizontal distance derived from x,y
to meters (so if it is lat/long, feet, or anything else defined in
PROJ_UNIT it converts it to meters)
si if you elevations are in anything else than meters - you have to
be careful and convert also your elevation to meters
because GRASS has no way of knowing you elevation units. So if your
elevation is in meters,
you should be fine. Let me know if not. I always project the lat/
long data because I work in smaller
areas and it is easier to work with x,y than long.lat so I have never
tried computation of slope
in long/lat, but by looking at the code it should work.But if I could tell grass that the z units were meters explicitly,
couldn't grass do the conversion automatically?as I explained above - GRASS assumes it is in meters.
Especially since the conversion changes as you move north.
yes, it uses geodesic to covert - that is what I was trying to say in
my email below:"If the projection is latitude-longitude, this distance is measured
along the geodesic."I hope this helps - it is kind of messy,
Helena
Jerry
---- Original message ----
Date: Thu, 12 Apr 2007 21:02:37 -0400
From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: [GRASS-dev] ascii export and import, large file problem
To: Gerald Nelson <gnelson@uiuc.edu>
Cc: grass-dev list <grass-dev@grass.itc.it>Jerry,
r.slope.aspect should work with lat-long, it calls G_distance that
saysThis routine computes the distance, in meters, from
* <b>x1</b>,<b>y1</b> to <b>x2</b>,<b>y2</b>. Two
* routines perform geodesic distance calculations.It should also support the wrap-around.
Maybe this should be added to the man page.
Helena
Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/On Apr 12, 2007, at 8:10 PM, Gerald Nelson wrote:
This is related to my earlier question (to which noone responded)
about why the slope calculation can't take lat-long data and just
figure out the slope from the z values.The srtm elevation data comes in lat-long values in cells that are
square. In order to get slope, which we need for a cost map, we
project to a utm value in the center of the region we need
(UTM37N). Grass does this projection and generates rectangular
pixels. Then we do the slope calculation and other things to
generate a cost surface.We need the ascii output to read the cost data into our custom
neural net program (because we don't have any C programmers, just a
java programmer).So its possible that what we observed when we did the export/import
process is a function of the square/rectangular pixel issue
interacting with the arc export/import that assumes pixels are
square.My ideal would be to not have to take the data out of lat-long, but
I have to do that to use the slope calculations.Hope this all makes some sense.
Regards, Jerry
---- Original message ----
Date: Thu, 12 Apr 2007 23:58:16 +0100
From: Glynn Clements <glynn@gclements.plus.com>
Subject: RE: [GRASS-dev] ascii export and import, large file
problem
To: "Jerry Nelson" <gnelson@uiuc.edu>
Cc: "'grass-dev'" <grass-dev@grass.itc.it>Jerry Nelson wrote:
I'm using grass6.3 updated today so the large file support for
the ascii
commands is included. I export a file using r.out.arc and then
read it back
in using r.in.arc. The attached jpg shows the original raster
on the right.
The screen on the left is the original raster minus the
exported and
imported version. The bottom two thirds or so of the left
raster is zero, as
it should be, but the top 1/3 has a bunch of small values
(range is - to
+2.9).My first guess is that the export->import process is changing the
vertical extent of the map slightly, so the calculation in the
upper
portion of the map is using cells which are off by one row.What does r.info say about the bounds of the two maps?
To provide more info,
The 'after' info
Rows: 21048
Res: 119.047796
The 'before' info
Rows: 21048
Res: 119.05225396
119.05225396 - 119.047796 = 0.00445796
0.00445796 * 21048 = 93.8311421So, the imported map has shrunk by almost a whole cell. That would
certainly explain the results.Ah, I see where the problem lies:
The 'before' info
Res: 119.05225396
Res: 119.04779557Your cells aren't square, but the ArcGrid format doesn't appear to
allow for non-square cells (single "cellsize" value rather than
separate x/y values). r.out.arc uses the horizontal resolution for
the
cellsize value; if the vertical resolution is different, you lose.This specific issue can't be fixed. However, if the original
data had
square cells, something is going wrong on the initial import.We might want to add a check for this to r.out.arc. We can't
actually
do anything beyond warn you that exporting will lose information,
although that's better than nothing.--
Glynn Clements <glynn@gclements.plus.com>Gerald Nelson
Professor, Dept. of Agricultural and Consumer Economics
University of Illinois, Urbana-Champaign
office: 217-333-6465
cell: 217-390-7888
315 Mumford Hall
1301 W. Gregory
Urbana, IL 61801_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-devGerald Nelson
Professor, Dept. of Agricultural and Consumer Economics
University of Illinois, Urbana-Champaign
office: 217-333-6465
cell: 217-390-7888
315 Mumford Hall
1301 W. Gregory
Urbana, IL 61801
Gerald Nelson
Professor, Dept. of Agricultural and Consumer Economics
University of Illinois, Urbana-Champaign
office: 217-333-6465
cell: 217-390-7888
315 Mumford Hall
1301 W. Gregory
Urbana, IL 61801