[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.2 Component: Vector| Version: svn-develbranch6 Resolution: invalid |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Comment(by hamish): Replying to [comment:8 mmetz]: It's not v.in.ascii, it's G_getl2() that fails to fetch the whole line, probably because of some obscure encoding of the output of las2txt which I am not able to figure out, or las2txt writes weird characters for empty fields. Hi, instead of piping to v.in.ascii can you save to a file which we can have a peek at in hexdump? what version of las2txt? does the same happen with the snake lidar sample data from the grass wiki lidar page or just this dataset? (if you found it others probably will too) Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/198#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.2 Component: Vector| Version: svn-develbranch6 Resolution: invalid |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Comment(by mmetz): Replying to [comment:9 hamish]: Replying to [comment:8 mmetz]: It's not v.in.ascii, it's G_getl2() that fails to fetch the whole line, probably because of some obscure encoding of the output of las2txt which I am not able to figure out, or las2txt writes weird characters for empty fields. Hi, instead of piping to v.in.ascii can you save to a file which we can have a peek at in hexdump? what version of las2txt? does the same happen with the snake lidar sample data from the grass wiki lidar page or just this dataset? las2txt version: libLAS 1.6.1 with GeoTIFF 1.3.0 GDAL 1.8.0 LASzip 1.2.0 The same happens with Serpent Mound Model LAS Data.las from the grass wiki lidar page. Attached is the las2txt output for srs.laz. I am pretty sure this problem is caused by las2txt which does not check if a given attribute exists. If it does not exist, some weird value is written. Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/198#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: closed
Priority: critical | Milestone: 6.4.2
Component: Vector| Version: svn-develbranch6
Resolution: invalid |Keywords: v.in.ascii
Platform: All | Cpu: All
---+
Comment(by hamish):
Replying to [comment:10 mmetz]:
Attached is the las2txt output for srs.laz.
I am pretty sure this problem is caused by las2txt which does
not check if a given attribute exists. If it does not exist,
some weird value is written.
correct. columns 6 and 7 are not empty.
as viewed in `less`:
{{{
289814.15|4320978.61|170.76|499450.80599405|260|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289814.64|4320978.84|170.76|499450.80600805|280|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289815.12|4320979.06|170.75|499450.80602205|280|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289815.60|4320979.28|170.74|499450.80603605|280|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289816.08|4320979.50|170.68|499450.80605005|260|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289816.56|4320979.71|170.66|499450.80606405|240|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289817.03|4320979.92|170.63|499450.80607806|240|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289817.53|4320980.16|170.62|499450.80609206|280|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289818.01|4320980.38|170.61|499450.80610606|280|^@|^@|6|0|2|Ground|0|0|0|0|0|0
289818.50|4320980.59|170.58|499450.80612006|260|^@|^@|6|0|2|Ground|0|0|0|0|0|0
}}}
`^@` means the null char.
I think it is reasonable for G_getl2() to stop on null terminators, and
there's nothing more to do here but file a bug with `las2txt`.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:11
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.2 Component: Vector| Version: svn-develbranch6 Resolution: invalid |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Comment(by mmetz): Replying to [comment:11 hamish]: Replying to [comment:10 mmetz]: Attached is the las2txt output for srs.laz. I am pretty sure this problem is caused by las2txt which does not check if a given attribute exists. If it does not exist, some weird value is written. correct. columns 6 and 7 are not empty. [snip] I think it is reasonable for G_getl2() to stop on null terminators, and there's nothing more to do here but file a bug with `las2txt`. I would rather call this a user error that I did because the proper way to do it would be to investigate the .la[s|z] file first with `lasinfo`, decide what attributes I want to import based on the attributes available and then set the --parse options accordingly. Or use v.in.lidar which does it all automatically;-) Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/198#comment:12 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.2 Component: Vector| Version: svn-develbranch6 Resolution: invalid |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Changes (by mmetz): * status: reopened = closed * resolution: = invalid Comment: Replying to [comment:7 mmetz]: Still not working. Test data are LiDAR laz data available here http://liblas.org/samples/ The file I used is srs.laz [snip] # only the first 5 columns were imported It's not v.in.ascii, it's G_getl2() that fails to fetch the whole line, probably because of some obscure encoding of the output of las2txt which I am not able to figure out, or las2txt writes weird characters for empty fields. Closing as invalid. -- Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.2
Component: Vector| Version: svn-develbranch6
Resolution:|Keywords: v.in.ascii
Platform: All | Cpu: All
---+
Changes (by mmetz):
* status: closed = reopened
* resolution: fixed =
* milestone: 6.4.1 = 6.4.2
Comment:
Still not working. Test data are LiDAR laz data available here
http://liblas.org/samples/
The file I used is srs.laz
The commands
{{{
las2txt -i srs.laz -o srs.ascii --parse xyztiaunrcCpedRGB --delimiter |
# check ascii file
head srs.ascii
289814.15|4320978.61|170.76|499450.80599405|260|||6|0|2|Ground|0|0|0|0|0|0
289814.64|4320978.84|170.76|499450.80600805|280|||6|0|2|Ground|0|0|0|0|0|0
289815.12|4320979.06|170.75|499450.80602205|280|||6|0|2|Ground|0|0|0|0|0|0
# import in GRASS
las2txt -i srs.laz --stdout --parse xyztiaunrcCpedRGB --delimiter | |
v.in.ascii in=- out=srs_ascii -z x=1 y=2 z=3 --o
# only the first 5 columns were imported
# check table contents
v.db.select srs_ascii where=cat = 1
cat|dbl_1|dbl_2|dbl_3|dbl_4|int_1
1|289814.15|4320978.61|170.76|499450.80599405|260
}}}
Markus M
--
Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:7
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.1 Component: Vector| Version: svn-develbranch6 Resolution: fixed |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Changes (by martinl): * status: new = closed * resolution: = fixed Comment: Replying to [comment:5 martinl]: Replying to [comment:2 hamish]: patch applied in 6.5 and 7; looks like it's fine but deferring backport to relbr64 until 6.4.1 to allow more testing. it's already in relbr64. So can we close the ticket? Closing for now. -- Ticket URL: http://trac.osgeo.org/grass/ticket/198#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked +--- Reporter: hamish | Owner: grass-...@… Type: defect | Status: new Priority: critical| Milestone: 6.4.1 Component: Vector | Version: svn-develbranch6 Keywords: v.in.ascii |Platform: All Cpu: All | +--- Changes (by martinl): * cc: martinl (added) Comment: Replying to [comment:2 hamish]: patch applied in 6.5 and 7; looks like it's fine but deferring backport to relbr64 until 6.4.1 to allow more testing. it's already in relbr64. So can we close the ticket? -- Ticket URL: http://trac.osgeo.org/grass/ticket/198#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.1 Component: Vector| Version: svn-develbranch6 Resolution:|Keywords: v.in.ascii Platform: All | Cpu: All ---+ Changes (by hamish): * milestone: 6.4.0 = 6.4.1 Comment: patch applied in 6.5 and 7; looks like it's fine but deferring backport to relbr64 until 6.4.1 to allow more testing. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: Vector| Version: svn-develbranch6 Resolution:|Keywords: v.in.ascii Platform: All | Cpu: All ---+ Comment (by mmetz): Try attached patch for the missing values problem. NULL, nan or inf is still not recognized. There is however still a nonsense warning for completely empty columns declared double, but import is successful. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
