[GRASSLIST:8001] Re: Bug in r.out.arc

[Maciek Sieczka]

From: "David Finlayson" <david.p.finlayson at gmail.com>

> Have you tried using r.in.gdal/r.out.gdal? I wonder if r.out.arc
> shouldn't be depreciated in favor of gdal?

No, it shouldn't. GDAL forces INTEGER precision, when the ascii grid file
begins with more than 1024 bytes of nodata, as these are often given as
-9999 or similar. That happens even if the actual precision is FLOAT or 
DOUBLE!
r.in.arc is the only salvation then, as it can at least be forced to treat 
input as FLOAT or DOUBLE so we don't loose any data.

> On 8/19/05, Karl Broich <b61bro at b61srv5.bauv.unibw-muenchen.de> wrote:
>> Hello,
>>
>> The accuracy of outputformat in r.out.arc is inconsistant with GRASS
>> internal format.
>>

Karl,

>> GRASS uses internally an accuracy of 8 numbers.
>> r.out.arc writes out only 6
>> numbers.

For r.out.arc you can use  "dp=integer" option which lets you output as many
decimal places as you wish.

>> After export and reimport with r.in.arc into GRASS this is felt as an
>> mismatch of several cells at the east boundary. This error possibly
>> occurs
>> just on grids with n x n >> 1000 x 1000.

What if you "r.in.arc type=DCELL"? Does that solve your problem?

I used to have similar problems some time ago. Dig the grass5, grasslist and
gdal-dev archives wher kind Folks have explained a lot. On gdal-dev there's
been another discussion on this topic few days ago.

Maciek