[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