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

[Gerald Nelson]

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.

But if I could tell grass that the z units were meters explicitly, couldn't grass do the conversion automatically? Especially since the conversion changes as you move north.

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>. If the projection is
>* latitude-longitude, this distance is measured along the geodesic. 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