Strip ID for legs (survey XML)

[han16nah]

For dynamic platforms in HELIOS++, flight strips connect two defined points (legs). If we want to create a trajectory, that holds a fixed height over terrain (with some tolerance), we have to create several legs for one (in the x-y-plane) straight flight line, because the z-value has to be adjusted. In this example, we would currently end up with many small flight lines.

Therefore, it would be a great feature to have a flight_strip_id (or strip_id or id), which would be defined in the <leg> tags within the scanner XML to group legs into individual flight lines. In the output (point cloud and trajectory), points from legs with the same strip id should be written to one single file. If no id is provided, each leg is numbered incrementally (the way it is done currently).

This could also be useful for other cases, e.g., when recreating only parts of a real survey, which means some flight strip IDs might be missing or the strip IDs would not start with 0. Then the correct strip IDs could be assigned in the survey XML and HELIOS++ outputs could be immediately matched to real data via the strip IDs.

[albertoesmp]

Strip for legs implementation has been merged at https://github.com/3dgeo-heidelberg/helios/commit/1b687c173dbb5c74214ef7db42259a50dc9fa4e6

Please, check everything work as expected before closing the issue.

[han16nah]

LGTM! It's also documented in the Wiki now. I will add the feature to an existing demo survey or add a new survey and then close the issue.

[han16nah]

@albertoesmp After creating a demo survey, I noticed that the stripId work perfectly for xyz point clouds and for the trajectory. However, LAS/LAZ point cloud files are not properly merged and end up empty, corrupt or missing a large fraction of points.

Below, I am attaching two XML files with the same survey/the same legs, but one is using strip IDs to group the legs into four legs, the other one not. als_hd_height_above_terrain.zip The survey uses a geotiff scenepart, which is contained in the repository. Thus, the issue can be reproduced with the XML files after copying them to data\surveys by running:

run\helios data\surveys\als_hd_height_above_terrain_stripId.xml --lasOutput

or

run\helios data\surveys\als_hd_height_above_terrain_stripId.xml --lasOutput --zipOutput

The output can be evaluated using CloudCompare. It is expected to look the same as the xyz outputs, i.e., the outputs when executing the simulation without the lasOutput argument:

run\helios data\surveys\als_hd_height_above_terrain_stripId.xml

[miguelyermo-heidelberg]

Fixed (#176). The problem: .las/.laz files don't support append mode, so every new leg the corresponding .las file was closed and, when opened again, all the contents were being deleted.

There was two possible solutions for the problem, having each one a downside:

• The implemented solution supports the strips to be spread over all the surveys, i.e, the strips can be not consecutive without problem (leg000 -> strip000, leg001 -> strip001, leg002 -> strip000, etc). The downside is that all the .las files are closed at the end of the simulation, so they cannot be opened when its own leg is over. This happens even when there are no strips at all.
• If we want to be able to open the .las files as soon as its own strip ends, the strips must be placed consecutively in the survey file.

Let me know if you are happy with the implemented solution or you prefer the other proposal. @han16nah @lwiniwar

[lwiniwar]

"i.e, the strips can be not consecutive without problem (leg000 -> strip000, leg001 -> strip001, leg002 -> strip000, etc)."

so this means arbitrary combinations are allowed, and the files are only closed at the end? I don't mind this. But would it be possible to - at the end of a leg - look if this file will be written to in the future legs, and if not, close it already? Or is this more complicated than that?

[miguelyermo-heidelberg]

It is now implemented as you said. The corresponding .las file where a strip is being written is closed right after all the legs in the given strip are processed.