Page 1 of 1

[Discussion] Dealing with stations or points of view

Posted: Mon Jul 09, 2012 9:25 am
by jfhullo
Hi there,

When working with terestrial laser scanner data, it is really useful to be able to deal with the station info. A lot of functionnalities can be improved if using the origin of the station:
- translate rotate from station origin
- center point of view for segmentation
- stats and anlaysis from a point
- etc...

Ideally, such a station info should appear in the tree structure on the left. A station could be created when importing a point cloud, and/or edited in qCC. Realworks from trimble is a good example for dealing with station info.

I'm aware that such a change is not easy, but my opinion is that we should think about it since such info would allow numerous applications.

What's your opinion about it?

JFH

Re: [Discussion] Dealing with stations or points of view

Posted: Mon Jul 09, 2012 7:24 pm
by daniel
Indeed, there's a lot to be done. Originally, the 'sensor' object was meant to allow such operations. But I ran out of time (and it's generally hard to get all this information from ASCII files or other generic fiel formats).

Now that CloudCompare is able to read LAS and E57 files, it should be "easier" (we still need some time... or help however --> don't you have motivated interns or PhD students with a good C++ background at INSA Strasbourg? ;)

And can you maybe be more specific about the last point ("stats and analysis from a point")?

Best,

Re: [Discussion] Dealing with stations or points of view

Posted: Tue Jul 10, 2012 3:09 pm
by jfhullo
1. That's true that there is sensor objetcs. it's a good start. I think by using it properly with import and point clouds it could do the trick.

2. for stats, lots of errors in Terrestrial Laser Scanner (TLS) data have a polar coordinates structure. For example, the error in distance, the error in verticality of the rotation axis, etc. Then, if we know the origin of the local polar coordinate system, we are able to compute the sum of errors for each point, for example as a scalar field. Most (all) algortihms on point clouds use a global uncertainty, but this is a non-accurate approach in term of error budget.

Other idea come with the knowledge of the station that I forgot to mention in the previous point:
- a privilegiated direction for normal in a point P seen from station S is the vector PS.
- a plane reconstructed from a point of view is always a directional plane looking at the station and not the opposite. It can help to determine the faces of a wall for example.

etc...

Since I'm a surveyor, I can't think to a point cloud without thinking to its reference point of view...

Sadly, I'm writing my thesis and don't have a lot of time for coding right now. My students are not really excited by C++, which is sad to my opinion, but the cursus does not help.

I hope i'll have time a the end of my thesis for implementing the few ideas I have.

Cheers,

JFH