export automatically only vertices of transects

[Monica]

Hi,

I am using the extract cloud sections along polylines in CC. I have hundreds of lines in a nice polyline shapefile. I can extract automatically on these lines the point cloud and the contour lines. I would like to export only the vertices of these contour section lines, not the 3d polylines. I see that i can select automatically all the section contours but not only the vertices for each contour without selecting the section-lines themselves. Of course i can select each by hand without selecting the sections and exporting them as Multipoint MZ shapefiles or xyz tables.

So my question is: can i select all these vertices files automatically without the section-lines before exporting them as xyz tables? That would be great since i will have at least about 1000 sections per point cloud.

My secondary question is: How should i cite CloudCompare in an article i am writing?

Thanks so much for your time,

Monica

[daniel]

Hi,

You can use the latest beta version which has a new 'select by type' option:
- right click on the 'Extracted profiles' group in the DB tree
- select the 'Select children by type and/or name' option
- by default the type should be 'Point cloud' so imply click on ok

All 'vertices' clouds will be selected (even if you wont see it clearly as the vertices are hidden and the tree is collapsed by default).

The beta version can be found here:
http://www.cloudcompare.org/release/Clo ... in_x64.zip

P.S.: another solution would be to select all polylines (which is easier) and save them as 'Salome Hydro polylines (*.poly)'. You'll get all vertices in a single file, each polyline being separated by a blank line.

[daniel]

And to cite CC, see this post:
http://www.danielgm.net/cc/forum/viewtopic.php?t=146

[Monica]

Hi,

I am going to try the beta version right now. Thank you so much. I will let you know how i am getting along. This will be a tremendous help since all that data will go to some R scripts to extract some morphological features automatically.

Thanks, Monica

[Monica]

Hi again,

The beta version worked beautifully for what i needed. Do you have any document in which you go in more details than the user manual on how you extract the polyline section and it's vertices from the slice of point cloud? Does the vertex on the polyline is the closest point from the point cloud slice? I saw that it is based on a convex hull of the point cloud slice .... i guess i need to read that a little bit more.

Also, i would love to integrate some of the CloudCompare capabilities in some of my R scripts, is there any way i can call CloudCompare from inside R? In case you are not familiar with R (in case you are, sorry for the repetition) - this is an open source statistical programing environment http://cran.r-project.org/ Even if the 2 softwares cannot be integrated, your new beta version is helping me a lot and the export tool gets the data out in the right format for R.

Thanks so much,

Monica

[daniel]

Indeed, for profile extraction we start from the convex hull and then try to 'approximate' as best as possible the 'concave' hull (however there's no unicity of the concave hull definition so it's hard to guess what the user is expecting - and of course it's hard because it's a random point cloud).

You can use the 'debug mode' to try to understand how the algorithm works (it will show you the process in a graphical step by step mode).

And I know some people use CloudCompare with R via the command line tool (http://www.cloudcompare.org/doc/wiki/in ... _line_mode). However not all methods are available in this mode (yet).

[Monica]

Hi Daniel,

Thanks for your prompt replay. I tried to use the debug mode and i cannot say that i understood it - unfortunately. If you still can bear with me, i will try to add some screen capture to explain. So - what exactly the "max_edge_length" param does? From the little explanation i saw it supposed to make the profile contour closer to the points cloud, but making that param smaller i got some unexpected results - for me anyway.

So here it is the point cloud - already extracted along the transect - 0.5 m wide:


This is the result transect with max_edge_length = 1.9 m - the green line does not look as i expected


This is the result transect with max_edge_length = 2 m and this is the result i would have expected


And this is the combines image - as you see the lines are almost identical except in that peak the green line has.


The difference between 1.9 and 2 m is not that big - but certainly it is a big difference in the resulted transect line. If you have any idea why this is happening - please let me know. Just in case i will attach the point cloud itself as well - if you want to play with it.
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ans104.las

Thanks so much for any help you can provide,

Monica

[daniel]

First, I think that your slice is a bit too thick for the algorithm. And sadly the algorithm is also a bit too sensible to noise.

The basic idea is to start from the convex hull, and then to split the longest edge by connecting its two vertices to the nearest point in the cloud. If at least one of the new edges is smaller than the original one we continue the splitting process. Until we can't split the edges anymore or their length falls below 'min edge length'. Of course there are some more subtle tricks and heuristics but that's the basic idea.

In your case, something bad happens, probably due to these tricks and heuristics. The green edge is much smaller than the new ones but we have to do this sometimes to prevent the algorithm from being stuck (especially since the green edge is much bigger than the others).

contour_small_edge_length.jpg (29.35 KiB) Viewed 4026 times

Obviously something is wrong here. I'll try to look if we can fix this (I just don't know when I'll have the time to do this).

[daniel]

Finally I've added a 'multipass' option (disabled by default) to both section extraction algorithms. This way the second pass (that creates the long edges) can be avoided and it will fix your issue.

This second pass is only necessary when the profile is 'stuck' (this only occurs with highly concave profiles).

You can use the same link as previously (I've overwritten the former archive).

[Monica]

Hi Daniel,

I just tried your new beta version and it works very nicely. I didn't realized my point cloud slices are considered "thick" since i choose 0.5 m for that param. I was afraid to make them thinner since my point cloud density is not constant over the survey. Besides, this is my first time working with these type of lidar data and i was not sure what to expect. I will try a thinner slice as well. And i have portions of the survey over concave cliffs - actually that was the point of the survey in the first place since we cannot capture that covexity / concavity of the cliff faces with the usual aerial lidar surveys.

In the end all of that will go into a validation paper in which we will compare top and toe of the cliffs extracted outomatically from bare earth DEMs of aerial lidar data, GPS survey points and points extracted from ground lidar surveys. I am using CloudCompare to extract profiles for the ground lidar data since i cannot actually do a griding and still conserve the convexity / concavity of the cliff faces.

So again a big thank you,

Monica