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

[Gerald Nelson]

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