Opened 17 years ago
Last modified 12 years ago
#123 closed defect
r.in.xyz: import bug when using scanned extent — at Version 1
Reported by: | neteler | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 6.4.0 |
Component: | Raster | Version: | svn-trunk |
Keywords: | r.in.xyz | Cc: | grass-dev@… |
CPU: | Unspecified | Platform: | Unspecified |
Description (last modified by )
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 $i 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
Note:
See TracTickets
for help on using tickets.