rayimport point clouds with no trajectory infos

[redcat-sci]

Dear Thomas,
first of all thank you very much for sharing these outstanding CLI based tools (including treetools).
I'm working with a 16ha combined PC of a forest at 10 cm resolution (70M points) which does not contain information other than XYZ coordinates. No time, no RGB, etc & no trajectory file. I'm currently importing it with rayimport plyfile 0,0,0 and then I use your splitting script (well inspired by it) to extract trees terrain and so on with some success. I'm wonder of a few points:

1. while splitting, including overlap edges, I noticed (as noticed by someone else) that the central plot contains the same number of points (rays) of the original one (note that 0,0,0 is also the origin my reference system falling within the forest); and the number of rays drop towards the full scene boundaries plot. Is this behavior normal?
2. Lacking the trajectory file, may an approach based on multiple rayimport from different positions (e.g. 0,0,0; 100,0,0, ... and so on), followed by a raycombine -- which parameters?---, help defining a more complete starting point ray cloud (I imagine something like: trees viewed from different points)?

Thank you again for your work. kind regards
Christian

[thomas-lowe]

Hi Christian, I'm glad you're having some success.

1. Yes this is expected, raysplit grid cuts through rays, not just selecting points. So the centre grid will contain all the ray starts. These are marked as non return rays with alpha 0, and their end points are coloured black to help. You can remove them with raysplit alpha 0. If your cloud was collected with mobile mapping then you might want to do rayimport x.ply ray 0,0,-0.1 so all the rays are small and local. It will stop the cut rays when using raysplit grid.
2. Yes, tripod scans from multiple views is good. You can combine with raycombine (default params) but may have to rayalign first, but rayalign needs at least 30% overlap so auto align then.

[redcat-sci]

Thank you very much for the prompt answer. Despite it's not yet crystal clear to me what rayimport x.ply ray 0,0,-0.1 does (from where the ray are traced), it looks like I was able to obtain focused split files (without unwanted rays) following both your suggestions: 1) applying the raysplit orig_xgrid_ygrid.ply alpha 0 to each of previously raysplit gridded files (obtaining smaller files flagged as _outside: e.g. >the alpha values given as parameter, not outside the grid local bbox, the _inside (alpha<=0 in my case) containing the walls); or 2) by import the main PC w/ the ray nx,ny,nz param, and then raysplit it as grid, with very similar achievement. It looks like I will not explore the method based on raycombine, and not sure I well described the idea.

... 5-stars and counting!!

[thomas-lowe]

Looks alright. The ray parameter on rayimport is the ray vector from sensor to contact point. 0,0,-0.1 is forcing it to 10cm downwards. Typing rayimport with no parameters will give help.
Regarding gridding with overlap and recombining, see the rayextract_large.sh script in the scripts folder. Note the gridwidth parameter used in rayextract trees when overlap is present.