[GRASS5] shift bug in r.in.ascii/r.out.ascii

[Helena]

Markus Neteler wrote:

> On Thu, Jul 05, 2001 at 05:39:48PM -0500, Helena wrote:
> > Has anybody tested whether r.in.arc and r.out.arc does not have the same problem ?
> > At least one version of r.out.arc was written based on r.out.ascii so the bug might
> > have
> > been transfered there too.
> >
> > Helena
>
> I have just run the same test - it seems to be working alright.

thanks for testing it

>
> But... even here we have the precision problem:
>
> ncols 140
> nrows 144
> xllcorner 3568200
> yllcorner 5765462.5
> cellsize 12.500000
> NODATA_value -9999
> 126.870003 126.550003 126.25 125.93 125.599998
>        ^^^       ^^^^                    ^^^^^

Markus, the numbers are perfectly right for
floating point, if you want to have 9 digits (126.870000) then you would have
to store that number as double, which of course can be done but as we discussed
before do you want to have your milion cell DEM with vertical accuracy in dm stored
as doubles? I don't have a problem with this because this is a good reminder for me
how the data are stored and that it needs to be taken into account when running
the models. If it bothers you - change the output to just 7 digits. So for example if
you are using
r.out.ascii for floating point raster map and your elevations are say 100.000000 -
150.000000
you should use dp = 4 rather than the default 6, because the FP holds only 7 digits
(correct me somebody if I am not right). If you want those data output with 6 decimals
places
you would need double precission.
r.stats does not give you that choice so it may be useful to add it there and then there
are also
some programs which print out numbers with ridiculous number of digits, e.g. r.colors:
I counted 29 digits for r.colors data range when you run it with the rules option . That
should be
easy to fix.
As it was already discussed it would be possible to have grass automatically adjust
everything
related to fp to just 7 digits but there may be cases when this may be too restrictive.
Because nothing is really broken here maybe the best approach would be that whoever is
working
on a program where dp option should be added or number of digits for print out needs to
be adjusted
fixes that too, or when time allows it along with other more important things.

I guess that I have written more than I really wanted to,

Helena

>
>
> Same story as with r.stats, r.to.sites, r.in./out.ascii, r.in./out.arc.
>
> While the NULL thing is a severe change probably interesting for 5.1, the
> precision issue might be solved now.
>
> Regards
>
>  Markus
>
> > Glynn Clements wrote:
> >
> > > Markus Neteler wrote:
> > >
> > > > > > Looks to me as if fseek is moving one byte too far back in the buffer on
> > > > > > line 142 in r.in.ascii/cmd/gethead.c, putting the last digit of the number
> > > > > > of columns as the first cell value read. Since it is followed by a
> > > > > > newline, it is treated as value.
> > > > > >       fseek(fd, -(len+1), SEEK_CUR);
> > > > > >
> > > > > > For me,       fseek(fd, -(len), SEEK_CUR); fixes it, but I haven't tried
> > > > > > it with other header fields or command line options.
> > > > >
> > > > > Suggestion: call ftell() before G_getl() and use fseek(SEEK_SET) to
> > > > > restore the position. Alternatively, you could use fgetpos() and
> > > > > fsetpos(); these are more portable, but that probably isn't an issue
> > > > > here.
> > > >
> > > > Thanks for your help! I've tried Roger's suggestion and tested in a
> > > > Transverse Mercator and a lat/long location - it seems to work.
> > > >
> > > > This version is uploaded to CVS now.
> > > >
> > > > Glynn, do you think your idea is to be preferred?
> > >
> > > Yes.
> > >
> > > Basically, restoring the position to one which was previously recorded
> > > with ftell() or fgetpos() is more robust than trying to compute the
> > > required offset from the current file position.
> > >
> > > In this case, the code is assuming that the number of bytes by which
> > > G_getl() advances the stream's position is equal to the length of the
> > > string which G_getl() stores in the buffer.
> > >
> > > Whilst this may happen to be the case, I can't see anything which
> > > actually states that it is so (G_getl() doesn't appear to have an
> > > entry in progman50.pdf).
> > >
> > > Furthermore, the existing implementation of G_getl() suggests that it
> > > isn't the case as G_getl() removes the trailing newline. This implies
> > > that the original version (offset of "-(len+1)") should be correct;
> > > maybe there is another (equal-but-opposite) off-by-one bug elsewhere?
> > >
> > > There is another issue, which isn't applicable here but may be worth
> > > bearing in mind generally, which is that the behaviour of fseek() on a
> > > text (as opposed to binary) stream is undefined unless the offset is
> > > either zero, or the value returned from a previous call to ftell() (in
> > > the case of SEEK_SET).
> > >
> > > --
> > > Glynn Clements <glynn.clements at virgin.net>
> > > _______________________________________________
> > > grass5 mailing list
> > > grass5 at geog.uni-hannover.de
> > > http://www.geog.uni-hannover.de/mailman/listinfo/grass5
> >
> > _______________________________________________
> > grass5 mailing list
> > grass5 at geog.uni-hannover.de
> > http://www.geog.uni-hannover.de/mailman/listinfo/grass5
>
> --
> Markus Neteler *  University of Hannover
> Institute of Physical Geography and Landscape Ecology
> Schneiderberg 50 * D-30167 Hannover * Germany
> Tel: ++49-(0)511-762-4494  Fax: -3984
> _______________________________________________
> grass5 mailing list
> grass5 at geog.uni-hannover.de
> http://www.geog.uni-hannover.de/mailman/listinfo/grass5