[GRASS-dev] Segmentation fault using v.in.lidar

GRASS GIS GRASS GIS developer
1

Hi,

I've been trying to use v.in.lidar. It yields good results on one LAS
file, but I get a segfault when trying it on several files:

v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb

Segmentation fault

v.in.lidar in=BD32_161*.las out=test_input_lidar -trb

Segmentation fault

Am I missing something, or is it a bug?

Cheers,

Pierre

--
Scientist
Landcare Research, New Zealand

2

On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
<pierre.roudier@gmail.com> wrote:

Hi,

I've been trying to use v.in.lidar. It yields good results on one LAS
file, but I get a segfault when trying it on several files:

v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb

Segmentation fault

v.in.lidar in=BD32_161*.las out=test_input_lidar -trb

Segmentation fault

Am I missing something, or is it a bug?

v.in.lidar takes only one input file at a time.

Markus M

3

Thanks for the quick answer Markus,

That would be a nice feature to add though. A lot of the LAS files are
coming "tiled", and it'd be nice to be able to do something like:

v.in.lidar in=*.las out=test_input_lidar -trb

or

v.in.lidar in=zone_32_*.las out=test_input_lidar -trb

to import a special subset of LAS files.

I've very few coding abilities, so this is just meant as another line
on the wishlist :wink:

Thanks heaps for your work on *.in.lidar, it is working well otherwise,

Pierre

2011/7/13 Markus Metz <markus.metz.giswork@googlemail.com>:

On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
<pierre.roudier@gmail.com> wrote:

Hi,

I've been trying to use v.in.lidar. It yields good results on one LAS
file, but I get a segfault when trying it on several files:

v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb

Segmentation fault

v.in.lidar in=BD32_161*.las out=test_input_lidar -trb

Segmentation fault

Am I missing something, or is it a bug?

v.in.lidar takes only one input file at a time.

Markus M

--
Scientist
Landcare Research, New Zealand

4

Pierre,
I think the main issue with doing *.las would be that although LAS data is coming in tiled but is also available as overlapping swaths. I imagine to impliment the option for multiple las files you would need to build an internal index of the “footprint” of each input las file that tells r.in.lidar and v.in.lidar which file(s) to draw the input las data from to create the output. In the case of r.in.lidar, you would need to specify which files to simultaneously open to gather the point values to calculate the statistics that are the value of the output cell. You would need something like the way gdaltindex builds a polygon shape file from a list of input georeferenced images. ( Now if I only had some skill with C to throw together some code :frowning: )

In the short term, use the las2las command from liblas.org to merge your .las files into a single las file and then process the one file. You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that’s not an issue.

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Pierre Roudier <pierre.roudier@gmail.com>
Sent by: grass-dev-bounces@lists.osgeo.org

07/13/2011 03:05 AM

To

Markus Metz <markus.metz.giswork@googlemail.com>

cc

grass-dev <grass-dev@lists.osgeo.org>

Subject

Re: [GRASS-dev] Segmentation fault using v.in.lidar

Thanks for the quick answer Markus,

That would be a nice feature to add though. A lot of the LAS files are
coming "tiled", and it'd be nice to be able to do something like:

v.in.lidar in=*.las out=test_input_lidar -trb

or

v.in.lidar in=zone_32_*.las out=test_input_lidar -trb

to import a special subset of LAS files.

I've very few coding abilities, so this is just meant as another line
on the wishlist ;)

Thanks heaps for your work on *.in.lidar, it is working well otherwise,

Pierre

2011/7/13 Markus Metz <markus.metz.giswork@googlemail.com>:
> On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
> <pierre.roudier@gmail.com> wrote:
>> Hi,
>>
>> I've been trying to use v.in.lidar. It yields good results on one LAS
>> file, but I get a segfault when trying it on several files:
>>
>>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
>> Segmentation fault
>>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb
>> Segmentation fault
>>
>> Am I missing something, or is it a bug?
>
> v.in.lidar takes only one input file at a time.
>
> Markus M
>

--
Scientist
Landcare Research, New Zealand
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

5

On Wed, Jul 13, 2011 at 2:59 PM, <Doug_Newcomb@fws.gov> wrote:

    In the short term, use the las2las command from liblas\.org  to merge your \.las files into a single las file and then process the one file\.  You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that&#39;s not an issue\.

In GRASS 6, the limit is somewhere lower than 2 billion features
because GRASS vector files can't be larger than 2GB. In GRASS 7, it
should depend only on whether GRASS was compiled with Large File
Support. In all GRASS versions, the limit with topology is at 2^31 -
1 (about 2 billion) features.

Markus M

Pierre Roudier <pierre.roudier@gmail.com>
Sent by: grass-dev-bounces@lists.osgeo.org

07/13/2011 03:05 AM

To
Markus Metz <markus.metz.giswork@googlemail.com>
cc
grass-dev <grass-dev@lists.osgeo.org>
Subject
Re: [GRASS-dev] Segmentation fault using v.in.lidar

Thanks for the quick answer Markus,

That would be a nice feature to add though. A lot of the LAS files are
coming "tiled", and it'd be nice to be able to do something like:

v.in.lidar in=*.las out=test_input_lidar -trb

or

v.in.lidar in=zone_32_*.las out=test_input_lidar -trb

to import a special subset of LAS files.

I've very few coding abilities, so this is just meant as another line
on the wishlist :wink:

Thanks heaps for your work on *.in.lidar, it is working well otherwise,

Pierre

2011/7/13 Markus Metz <markus.metz.giswork@googlemail.com>:
> On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
> <pierre.roudier@gmail.com> wrote:
>> Hi,
>>
>> I've been trying to use v.in.lidar. It yields good results on one LAS
>> file, but I get a segfault when trying it on several files:
>>
>>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
>> Segmentation fault
>>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb
>> Segmentation fault
>>
>> Am I missing something, or is it a bug?
>
> v.in.lidar takes only one input file at a time.
>
> Markus M
>

--
Scientist
Landcare Research, New Zealand
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

Doug, Markus,

Thanks for the interesting discussion,

In the short term, use the las2las command from liblas.org to merge your .las files into a single las file and then process the one file.

Yes at the moment, my workflow is:

ls ID_*.las > las_list.txt
lasmerge -i las_list.txt -o out.las
v.in.lidar in=out.las out=lidar -trb

Works very well. I was just wondering how difficult it would be to use
wildcards directly in the input=... option. Obviously it requires some
significant amount of work.

You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that's not an issue.

Indeed, not an issue for me (unfortunately!),

In all GRASS versions, the limit with topology is at 2^31 -
1 (about 2 billion) features.

I usually never build the topology of my LiDAR point clouds. Should I do it?

Cheers,

Pierre

Pierre Roudier <pierre.roudier@gmail.com>
Sent by: grass-dev-bounces@lists.osgeo.org

07/13/2011 03:05 AM

To
Markus Metz <markus.metz.giswork@googlemail.com>
cc
grass-dev <grass-dev@lists.osgeo.org>
Subject
Re: [GRASS-dev] Segmentation fault using v.in.lidar

Thanks for the quick answer Markus,

That would be a nice feature to add though. A lot of the LAS files are
coming "tiled", and it'd be nice to be able to do something like:

v.in.lidar in=*.las out=test_input_lidar -trb

or

v.in.lidar in=zone_32_*.las out=test_input_lidar -trb

to import a special subset of LAS files.

I've very few coding abilities, so this is just meant as another line
on the wishlist :wink:

Thanks heaps for your work on *.in.lidar, it is working well otherwise,

Pierre

2011/7/13 Markus Metz <markus.metz.giswork@googlemail.com>:
> On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
> <pierre.roudier@gmail.com> wrote:
>> Hi,
>>
>> I've been trying to use v.in.lidar. It yields good results on one LAS
>> file, but I get a segfault when trying it on several files:
>>
>>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
>> Segmentation fault
>>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb
>> Segmentation fault
>>
>> Am I missing something, or is it a bug?
>
> v.in.lidar takes only one input file at a time.
>
> Markus M
>

--
Scientist
Landcare Research, New Zealand
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Scientist
Landcare Research, New Zealand

7

On Thu, Jul 14, 2011 at 1:06 AM, Pierre Roudier
<pierre.roudier@gmail.com> wrote:

Doug, Markus,

Thanks for the interesting discussion,

In the short term, use the las2las command from liblas.org to merge your .las files into a single las file and then process the one file.

Yes at the moment, my workflow is:

ls ID_*.las > las_list.txt
lasmerge -i las_list.txt -o out.las
v.in.lidar in=out.las out=lidar -trb

Works very well. I was just wondering how difficult it would be to use
wildcards directly in the input=... option. Obviously it requires some
significant amount of work.

...only if wildcard support is to be included in v.in.lidar. Your
example above is only three short lines. Put them in a little script
with one input option las_files and one output option vector, that's
it.

You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that's not an issue.

Indeed, not an issue for me (unfortunately!),

In all GRASS versions, the limit with topology is at 2^31 -
1 (about 2 billion) features.

I usually never build the topology of my LiDAR point clouds. Should I do it?

No, only if needed, i.e. if you want to process the imported point
clouds with a module that needs topology.

Markus M

Pierre Roudier <pierre.roudier@gmail.com>
Sent by: grass-dev-bounces@lists.osgeo.org

07/13/2011 03:05 AM

To
Markus Metz <markus.metz.giswork@googlemail.com>
cc
grass-dev <grass-dev@lists.osgeo.org>
Subject
Re: [GRASS-dev] Segmentation fault using v.in.lidar

Thanks for the quick answer Markus,

That would be a nice feature to add though. A lot of the LAS files are
coming "tiled", and it'd be nice to be able to do something like:

v.in.lidar in=*.las out=test_input_lidar -trb

or

v.in.lidar in=zone_32_*.las out=test_input_lidar -trb

to import a special subset of LAS files.

I've very few coding abilities, so this is just meant as another line
on the wishlist :wink:

Thanks heaps for your work on *.in.lidar, it is working well otherwise,

Pierre

2011/7/13 Markus Metz <markus.metz.giswork@googlemail.com>:
> On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
> <pierre.roudier@gmail.com> wrote:
>> Hi,
>>
>> I've been trying to use v.in.lidar. It yields good results on one LAS
>> file, but I get a segfault when trying it on several files:
>>
>>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
>> Segmentation fault
>>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb
>> Segmentation fault
>>
>> Am I missing something, or is it a bug?
>
> v.in.lidar takes only one input file at a time.
>
> Markus M
>

--
Scientist
Landcare Research, New Zealand
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Scientist
Landcare Research, New Zealand