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

[Markus Neteler]

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.

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
       ^^^       ^^^^                    ^^^^^

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