[GRASS-dev] [GRASS GIS] #123: r.in.xyz: import bug when using scanned extent

[Glynn Clements]

GRASS GIS wrote:

> #123: r.in.xyz: import bug when using scanned extent
> ---------------------+------------------------------------------------------
>  Reporter:  neteler  |       Owner:  grass-dev at lists.osgeo.org
>      Type:  defect   |      Status:  new                      
>  Priority:  major    |   Milestone:  6.4.0                    
> Component:  default  |     Version:  svn-trunk                
>  Keywords:           |  
> ---------------------+------------------------------------------------------
>  When using r.in.xyz in script style, points may get lost during import:
> 
>  Import script:
>  {{{
>  # for i in */*.txt
>  for i in d325095655/p325099657.txt
>  do
>   REGION=`r.in.xyz d325095655/p325099657.txt out=dummy fs=space -i --o -sg
>  | cut -d' ' -f1-4`
>   g.region $REGION res=1 -p
>   r.in.xyz $i out=`basename $i` fs=space -i --o
>  done
>  }}}
> 
> 
>  Result:
> 
>  {{{
>  GRASS 6.3.0svn (pat):~/data/lidar_PAT_raw/raw > sh import_all.sh
>  projection: 1 (UTM)
>  zone:       32
>  datum:      wgs84
>  ellipsoid:  wgs84
>  north:      5099457.35
>  south:      5099071.19
>  west:       657729.49
>  east:       657953.44
>  nsres:      1.00041451
>  ewres:      0.99977679
>  rows:       386
>  cols:       224
>  cells:      86464
>  Scanning data ...
>  Writing to map ...
>   100%
>  r.in.xyz complete. 3 points found in region.
>  }}}
> 
>  But:
> 
>  {{{
>  cat d325095655/p325099657.txt
>  657953.44 5099071.19 542.34
>  657753.59 5099457.35 327.69
>  657846.39 5099356.02 736.02
>  657729.49 5099357.89 585.16
>  }}}
> 
>  -> one line get's lost.

Which one? If it's the first line (the southernmost point), that's
probably due to this (raster/r.in.xyz/main.c:588):

	    if (y <= pass_south || y > pass_north) {

The problem with simply changing the test to < is that, for multiple
passes, any points on the boundary would be counted twice. The test
should be < for the last pass and <= for other passes.

Even for floating-point, copying a value and testing a value for
equality with itself should work as expected. Rounding errors don't
appear out of nowhere, and neither of those operations should
introduce rounding errors.

If GRASS is introducing rounding errors, the first step should be to
try to eliminate them (e.g. ensuring that decimal representations have
sufficient digits), rather than working around such errors by adding
tolerances.

-- 
Glynn Clements <glynn at gclements.plus.com>