Opened 9 years ago

Last modified 9 years ago

#573 new task

Roll Offsets Automation Script

Reported by: dac Owned by: dac
Priority: immediate Milestone: The Glorious Future
Component: alsproc Keywords:
Cc: Other processors:

Description

A ticket to keep track of any problems with the script being developed to automate finding pitch and roll values for lidar data.

More details on the script are available here:

https://arsf-dan.nerc.ac.uk/trac/wiki/Processing/Procedures/AlsprocAutoPitchRoll

Change History (6)

comment:1 follow-up: Changed 9 years ago by tec

Pitch, roll and heading values in filename are not of the same length, aka 0.0060 -> 0.006, making the numbers a fixed length would be nice, least then looking at all the files is easier on the eyes

comment:2 follow-up: Changed 9 years ago by tec

Fix code to determine what files to create when given a pitch/roll/heading range as if the range is perfectly divisible by the step then the last file is duplicated causing alsproc writing the header twice.

comment:3 in reply to: ↑ 1 Changed 9 years ago by dac

Have now fixed this. Could cause problems if the increments are very small as would end up with files having the same name.

Last edited 9 years ago by dac (previous) (diff)

comment:4 in reply to: ↑ 2 Changed 9 years ago by dac

Have fixed this. Was using <= when should have been using <.

Replying to tec:

Fix code to determine what files to create when given a pitch/roll/heading range as if the range is perfectly divisible by the step then the last file is duplicated causing alsproc writing the header twice.

comment:5 follow-up: Changed 9 years ago by tec

It seems to hang for a large amount of time when finding roll corrections when calculating the difference of DEMs and All-NaN slices are found.

Issue seems to be after line 483 in generate_align_image.py in the lidar_align_image library

comment:6 in reply to: ↑ 5 Changed 9 years ago by dac

I think this problem is due to an error in the method used to calculate if each block contains overlapping lines which is currently always returning true. When this is working correctly (which dap is looking into) the difference calculation should only run for blocks containing overlapping lines which should be faster.

Replying to tec:

It seems to hang for a large amount of time when finding roll corrections when calculating the difference of DEMs and All-NaN slices are found.

Issue seems to be after line 483 in generate_align_image.py in the lidar_align_image library

Note: See TracTickets for help on using tickets.