[GRASS-dev] ascii export and import, large file problem

Fri Apr 13 09:13:26 EDT 2007

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 at unity.ncsu.edu>
>> Subject: Re: [GRASS-dev] ascii export and import, large file problem
>> To: Gerald Nelson <gnelson at uiuc.edu>
>> Cc: grass-dev list <grass-dev at grass.itc.it>
>>
>> Jerry,
>>
>> r.slope.aspect should work with lat-long, it calls G_distance that  
>> says
>>
>> This 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 at gclements.plus.com>
>>>> Subject: RE: [GRASS-dev] ascii export and import, large file  
>>>> problem
>>>> To: "Jerry Nelson" <gnelson at uiuc.edu>
>>>> Cc: "'grass-dev'" <grass-dev at 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.8311421
>>>>
>>>> So, 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.04779557
>>>>
>>>> Your 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 at 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 at grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grass-dev
>>
> 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