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

Fri Apr 13 09:28:35 EDT 2007

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 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>
>
>
>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
>
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