.RXP missing information

151 views
Skip to first unread message

J. Antonio Guzman Quesada

unread,
Jun 28, 2019, 8:42:51 PM6/28/19
to pylidar

Dear group,

I am trying to run the pylidar_canopy code using pylidar on .rxp files derived from RIEGL VZ400i. However, it seems that some .rxp files tend to have missing information and I am not completely sure why. 

For example, when I try to get the information from well know test files using pylidar_info the routine provides a detailed description of the .rxp file, such as the image enclosed bellow.

Screenshot from 2019-06-25 11-01-56.png


However, when I try to get the information of .rxp files derived from our scans it seems to be a piece of missing information, such as the image enclosed below.

Screenshot from 2019-06-24 15-28-50.png


Since the file does not present complete information, I am not able to run other codes like pylidar_canopy. The files were created using 300kHz and 0.04 deg resolution vertical and horizontal in a RIEGL VZ400i.

My questions are: i) Is there any special configuration to the scanner to run these codes? ii) do we need to pre-process the .rxp files to run these codes? iii) how could we solve this problem?

We are new in this group so any help is always welcome. I saw some questions that seem to address a similar problem, but we are not clear about the solution.

Regards...

J. Antonio Guzman Q.


John David Armston

unread,
Jul 11, 2019, 5:29:02 PM7/11/19
to J. Antonio Guzman Quesada, pylidar
Hi,

Apologies for the delayed reply. All development of the RIEGL RXP driver has been on test files from the VZ400.
We just acquired a VZ400i, and I've replicated the same problem you show on our first scan.

My guess is the header structure in the RXP files have changed. After some more testing we'll update the driver as required.

John.

--
You received this message because you are subscribed to the Google Groups "pylidar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylidar+u...@googlegroups.com.
To post to this group, send email to pyl...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pylidar/bfec6862-c386-47d8-af02-5462419eaecb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
John Armston
1150 Lefrak Hall, Department of Geographical Sciences
University of Maryland, College Park MD 20742

John David Armston

unread,
Jul 11, 2019, 8:34:46 PM7/11/19
to J. Antonio Guzman Quesada, pylidar
Just had a look. For the VZ400i it seems the pose (scanner position and orientation) data is not written to the RXP file but to a different file for each scan position (yymmdd_hhmmss.pose). Unless supplied via the --externaltransformfn argument at the command line, pylidar_canopy methods for TLS voxelization and vertical profile generation need these pose data to orient the scan. 

Unless there's something I'm missing (quite possible!), we'll probably have to update the RIEGL driver or pylidar_canopy to read data from the *.pose files. In the meantime I suggest creating your own transform matrix using the pitch/roll/yaw from the yymmdd_hhmmss.pose, and providing to pylidar_canopy via the --externaltransformfn argument.

There is also setting on the scanner to do pose estimation for the first scan only or all scans. We had it set to the former... not sure if this makes a difference to where it is written.

John.

J. Antonio Guzman Quesada

unread,
Jul 12, 2019, 12:50:55 AM7/12/19
to John David Armston, pylidar
Dear Dr. Armston,

Yes, that is correct. The pitch/roll/yaw now appears in the .pose file and this needs to be defined in the workflow or during the scan. 

Unfortunately for me it was easier to develop my own code in R to estimate the number of pulses and returns per theta and h to get Pgap, than solve this in pylidar in a language that I do not know. In any case, I greatly appreciate your response and I hope that it will help anyone in the group.

Something interesting that maybe you have not noticed is that the .pose file appears per scan position. That's means, if you have two scans per scans position  (e.g. vertical, tilted) you may get just one .pose file. Therefore, for this aim we must use a scan per scan position. This is what I have observed with the instrument that we are using, I do not know if it's a rule.

Again, thank you for your response!

Antonio...



--
_______________________
J. Antonio Guzmán Q., M.Sc
Ph.D Candidate - Vanier scholar
Earth and Atmospheric Sciences Department
University of Alberta, Canada
Look my work in Google Scholar and/or ResearchGate

nick goodwin

unread,
Jul 12, 2019, 1:21:08 AM7/12/19
to J. Antonio Guzman Quesada, John David Armston, pylidar
Hey Antonio,

Our VZ400i scanner automatically increments a new position as soon as you tilt the scanner so that you will always get a new position and .pose file.. I'm guessing this feature should be available to turn on? Having only one .pose file for two positions could be challenging to work with.. 

Cheers

Nick 

Reply all
Reply to author
Forward
0 new messages