Hi Daniel,
Please let me know if you have more time to spend on my questions. I think somehow my pointcloud is kind of screwy .... somehow maybe the points should have been in a certain order or such .... i don't know. I have other slices of the pointcloud that behave even stranger than the one i posted earlier. If you are interested i can post few others .... for now i think i can go around the problem in using only the vertices of the transects but not the order the points are in .... in the sense that if i would connect those points by hand i would get a different shape of the line transects than the one CloudCompare generates, and this is because the vertices are generated out of order ..... For what i need to do i think this is not a major problem, although some sections of the pointcloud slice seems to not be processed al all .... now my slices are 0.1 m thick.
Either way, again thank you so much for all the help,
Monica
export automatically only vertices of transects
Re: export automatically only vertices of transects
Yes, don't hesitate to send more datasets. It will help me understand what's broken (I'm always happy to get some feedback from users and to enhance the software of course ;).
Daniel, CloudCompare admin
Re: export automatically only vertices of transects
Hi,
Thanks so much. I would not say that the software is not doing what is coded to do. Since i do quite a bit a geomorphology and trying to automate different feature extraction i know how hard it is to have one code to answer to all cases, and i know some are just too different from the majority that they need special treatment or just forget about it. It may be a trivial thing for the human eye to extract features, but less so when we want to do it automatically by machine.
That being said, i will post several little slices of t-lidar data. The data represent a part of a beach and it's cliffs, the point density is not constant and sometimes there are only one or 2 points in the beach, a higher density on the cliff face and even higher density of points on the top of the cliff. In the end the whole excercise is to extract automatically the top and the toe of the cliff from profiles pseudo-perpendicular to the cliff, plus some other important points of inflections and to characterise the face of the cliff in terms of convexity and concavity. So i recognize the data is not perfect but I have to work with it.
The slices are 0.1 m wide. This one is behaving as i expected - it's let's say - for reference ;-)
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_139.las
The following are not. Some of the problems are because there are only one or very few points on the beach, but even though i still don't understand why portions of the points towards the top of the cliff are actually ignored in the extract profile tool. Of course i am after the lower profiles - the equivalent of bare-earth. The points in this pointcloud are not classified, actually the pointcloud was minimally processed except a good georeference.
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_140.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_144.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_147.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_148.las
The poitcloud 147 has some points on the face of the cliff like a kind of weird outliers .... they might be the top of a bush or some other kind of vegetation, but there are points underneath for using for the lower line so it should not pick up those .... or at least i would like it so ;-)
In the end i will have to extract probably between 5000 to 8000 profiles from different sites, so of course i hope for the process to be as automated as possible.
Thanks for your continuous interest, please let me know if i can help in any way or send any more explanations.
Monica
Thanks so much. I would not say that the software is not doing what is coded to do. Since i do quite a bit a geomorphology and trying to automate different feature extraction i know how hard it is to have one code to answer to all cases, and i know some are just too different from the majority that they need special treatment or just forget about it. It may be a trivial thing for the human eye to extract features, but less so when we want to do it automatically by machine.
That being said, i will post several little slices of t-lidar data. The data represent a part of a beach and it's cliffs, the point density is not constant and sometimes there are only one or 2 points in the beach, a higher density on the cliff face and even higher density of points on the top of the cliff. In the end the whole excercise is to extract automatically the top and the toe of the cliff from profiles pseudo-perpendicular to the cliff, plus some other important points of inflections and to characterise the face of the cliff in terms of convexity and concavity. So i recognize the data is not perfect but I have to work with it.
The slices are 0.1 m wide. This one is behaving as i expected - it's let's say - for reference ;-)
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_139.las
The following are not. Some of the problems are because there are only one or very few points on the beach, but even though i still don't understand why portions of the points towards the top of the cliff are actually ignored in the extract profile tool. Of course i am after the lower profiles - the equivalent of bare-earth. The points in this pointcloud are not classified, actually the pointcloud was minimally processed except a good georeference.
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_140.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_144.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_147.las
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ns_148.las
The poitcloud 147 has some points on the face of the cliff like a kind of weird outliers .... they might be the top of a bush or some other kind of vegetation, but there are points underneath for using for the lower line so it should not pick up those .... or at least i would like it so ;-)
In the end i will have to extract probably between 5000 to 8000 profiles from different sites, so of course i hope for the process to be as automated as possible.
Thanks for your continuous interest, please let me know if i can help in any way or send any more explanations.
Monica
Re: export automatically only vertices of transects
Hi again,
I could not - not sent you this new pointcloud that is a section for which it does not matter what value i am using for the max-edge, a big part of the profile is ignored. The pointcloud slice as usual is 0.1m thick and it obviously has some vegetation on top and the sides. I was thinking that this may be a good example to play with. Meanwhile i am thinking what else i can do to extract the line i want - maybe in R since the pointcloud slices are small enough for R to deal with. If i come up with any idea i will let you know - if you are interested.
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ans133.las
Thanks again for all your help and interest,
Monica
I could not - not sent you this new pointcloud that is a section for which it does not matter what value i am using for the max-edge, a big part of the profile is ignored. The pointcloud slice as usual is 0.1m thick and it obviously has some vegetation on top and the sides. I was thinking that this may be a good example to play with. Meanwhile i am thinking what else i can do to extract the line i want - maybe in R since the pointcloud slices are small enough for R to deal with. If i come up with any idea i will let you know - if you are interested.
ftp://ftpext.usgs.gov/pub/er/va/reston/ ... ans133.las
Thanks again for all your help and interest,
Monica
Re: export automatically only vertices of transects
Okay I'll look at all this when I'll have some time ;)
Daniel, CloudCompare admin
Re: export automatically only vertices of transects
Okay, I looked at the first slices you sent me.
I got globally good results with the 'Section extraction' tool (max edge lenght = 0.4)... apart for a few "details" ;)
For the last dataset you sent me (cliff_7_trans133), I found this same 'overhang' limitation:
Which can be overcome by rotating the cloud:
Maybe we should change how the 'lower' and 'upper' profiles are determined (but how?). Or simply add a systematic rotation parameter...
I got globally good results with the 'Section extraction' tool (max edge lenght = 0.4)... apart for a few "details" ;)
- in presence of outlier points:
- cc_profile_outlier.jpg (15.08 KiB) Viewed 2238 times
- or more generally when the "overhang" is too strong: this is due to what we consider being the 'upper' and 'lower' profiles. In effect we look for the left-most and the right-most points and then we split the full contour in two parts relatively to those extreme points.
- cc_overhang.jpg (21.18 KiB) Viewed 2238 times
For the last dataset you sent me (cliff_7_trans133), I found this same 'overhang' limitation:
- cc_cliff_7_trans133.jpg (19.93 KiB) Viewed 2238 times
- cc_cliff_7_trans133_rotated.jpg (59.38 KiB) Viewed 2238 times
Daniel, CloudCompare admin
Re: export automatically only vertices of transects
Hi,
Sorry it took me a while to answer and thanks for actually looking at those profiles. The very idea was to use t-lidar to actually map the overhang of the coastal cliffs and after extract transects that are processed automatically to get top and toe of the cliff and few other significant inflection points on the face of the cliff and after to look at the face concavity and convexity. Cliff erosion is a big problem on west US coast. I also realized that if the points in the profile are ordered either from landward to seaward or reverse then the profile extraction works fine, otherwise i may get unwanted results. I spend some time to figure out a way to order either the points or extract the lower margin but now i am thinking if it is possible to extract just a transect that is a kind of "average" or "median" distance in between what is considered the upper and the lower transect.
At this stage i ignore all the profiles that were incorect (that means having sections missing - about 7 to 10% of all profiles from over a 1000) but i kept the ones that have points in the wrong order and give profiles with a kind of "double" lines for a lack of good descriptive words. In the end i used the points directly and not the line itself. The code in R is more complex because of that and has a little bit more heuristics than i would like, but the end results are quite good. I have ground control points and for the top of the cliff the RMSE is 0.5 m which is not too bad. Of course i would love to have better results still.
Hopefully in the end i will get results good enough to report to the fall AGU in San Francisco this year, we will see.
Again, thanks a lot,
Monica
Sorry it took me a while to answer and thanks for actually looking at those profiles. The very idea was to use t-lidar to actually map the overhang of the coastal cliffs and after extract transects that are processed automatically to get top and toe of the cliff and few other significant inflection points on the face of the cliff and after to look at the face concavity and convexity. Cliff erosion is a big problem on west US coast. I also realized that if the points in the profile are ordered either from landward to seaward or reverse then the profile extraction works fine, otherwise i may get unwanted results. I spend some time to figure out a way to order either the points or extract the lower margin but now i am thinking if it is possible to extract just a transect that is a kind of "average" or "median" distance in between what is considered the upper and the lower transect.
At this stage i ignore all the profiles that were incorect (that means having sections missing - about 7 to 10% of all profiles from over a 1000) but i kept the ones that have points in the wrong order and give profiles with a kind of "double" lines for a lack of good descriptive words. In the end i used the points directly and not the line itself. The code in R is more complex because of that and has a little bit more heuristics than i would like, but the end results are quite good. I have ground control points and for the top of the cliff the RMSE is 0.5 m which is not too bad. Of course i would love to have better results still.
Hopefully in the end i will get results good enough to report to the fall AGU in San Francisco this year, we will see.
Again, thanks a lot,
Monica