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

[Glynn Clements]

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>