Hello,
The accuracy of outputformat in r.out.arc is inconsistant with GRASS internal format.
GRASS uses internally an accuracy of 8 numbers. r.out.arc writes out only 6 numbers.
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.
Example :
Original North/West corner :
n =28.64083333
w =37.45333333
res=0.00083333
After export with r.out.arc :
n =28.640833
w =37.453333
res=0.000833
The error increases with lower res.
Work arround : Add the missing numbers manually inside your ascii-grid-file.
This bug is reported with no. 3546.
Karl
--------------------------------------------------------------------------
Dr.-Ing. Karl BROICH Tel: +49 / (0) 89 / 6004 2478
Universität der Bundeswehr München Fax: +49 / (0) 89 / 6004 3858
Institut für Wasserwesen
Werner-Heisenberg-Weg 39
D 85577 Neubiberg
--------------------------------------------------------------------------
Have you tried using r.in.gdal/r.out.gdal? I wonder if r.out.arc
shouldn't be depreciated in favor of gdal?
David
On 8/19/05, Karl Broich <b61bro@b61srv5.bauv.unibw-muenchen.de> wrote:
Hello,
The accuracy of outputformat in r.out.arc is inconsistant with GRASS
internal format.
GRASS uses internally an accuracy of 8 numbers. r.out.arc writes out only 6
numbers.
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.
Example :
Original North/West corner :
n =28.64083333
w =37.45333333
res=0.00083333
After export with r.out.arc :
n =28.640833
w =37.453333
res=0.000833
The error increases with lower res.
Work arround : Add the missing numbers manually inside your ascii-grid-file.
This bug is reported with no. 3546.
Karl
--------------------------------------------------------------------------
Dr.-Ing. Karl BROICH Tel: +49 / (0) 89 / 6004 2478
Universität der Bundeswehr München Fax: +49 / (0) 89 / 6004 3858
Institut für Wasserwesen
Werner-Heisenberg-Weg 39
D 85577 Neubiberg
--------------------------------------------------------------------------
--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA
Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays
--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA
Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays
From: "David Finlayson" <david.p.finlayson@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@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