[GRASS5] shift bug in r.in.ascii/r.out.ascii
Markus Neteler
neteler at geog.uni-hannover.de
Mon Jul 2 05:16:22 EDT 2001
On Fri, Jun 29, 2001 at 07:08:58PM +0100, Glynn Clements wrote:
>
> Roger Bivand wrote:
>
> > > just found (obviously) a bug in r.in.ascii/r.out.ascii:
> > >
> > > if you export/import the same map several times, it get's
> > > shifted each time!
> > >
> > > r.out.ascii in=dem out=dem0.asc
> > > r.in.ascii in=dem0.asc out=dem1
> > >
> > > r.out.ascii in=dem1 out=dem1.asc
> > > r.in.ascii in=dem1.asc out=dem2
> > >
> > > r.out.ascii in=dem2 out=dem2.asc
> > > r.in.ascii in=dem2.asc out=dem3
> > > d.rast dem
> > > d.rast dem1
> > > d.rast dem2
> > > d.rast dem3
> > >
> > > As being lack of time today, any volunteers?
> >
> > 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?
Markus
More information about the grass-dev
mailing list