Opened 16 years ago

Last modified 12 years ago

#123 closed defect

r.in.xyz: import bug when using scanned extent — at Initial Version

Reported by: neteler Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: Raster Version: svn-trunk
Keywords: r.in.xyz Cc: grass-dev@…
CPU: Unspecified Platform: Unspecified

Description

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.

If I add the "-a" flag to g.region above, it works.

I suspect that a test against GRASS_EPSILON is needed somewhere.

Markus

Change History (0)

Note: See TracTickets for help on using tickets.