Review ply2las extractor and output

[max-zilla]

Review issue for the ply2las extractor and output using 3dscanner PLY inputs.

Completion criteria:

• [ ] Code review complete (includes extractor, any functions in terrautils, etc)
• [ ] Sample data output verified
• [ ] Sample metadata verified
• [ ] Changes for 2017 release implemented
• [ ] Quality statement in extractor readme stating assumptions / limitations of use
• [ ] Issue(s) for changes postponed until 2018 created
• [ ] Extractor tagged/versioned
• [ ] Extractor deployed
• [ ] Final output verified/reviewed

[max-zilla]

Example output dataset: https://terraref.ncsa.illinois.edu/clowder/datasets/59bac9c44f0c0b27bc3d3132

And the raw PLY files used to create that dataset: https://terraref.ncsa.illinois.edu/clowder/datasets/59ba97314f0c0b27bc3d0529 (this is linked in metadata of Lv1 data too but I fixed a bug today that was omitting /clowder/ from the link URLs so the one in the example dataset is broken)

...other LAS datasets from that same day: https://terraref.ncsa.illinois.edu/clowder/collection/59bab79c4f0c0b27bc3d2901

These merged LAS files live in

sites/ua-mac/Level_1/scanner3DTop/2017-07-03/

Currently the LAS files are stored alongside the PLY files that generated them.

[dlebauer]

It is not clear what the location or scale of the LAS points are. When I open in cloudcompare I get the following information:

It appears that the scale of these numbers (xyz dimensions) might be mm, as this would but the bounding box size as 1.5m wide x 27 m long x 2.6 m tall. However, the box center at 0, 8.6, -1.3 does not seem consistent with the point cloud origin in the metadata.

[dlebauer]

@solmazhajmohammadi the key question is: how can someone query this las file given an x,y or lat,lon bounding box?

[solmazhajmohammadi]

This issue is not related to conversion. PLY to LAS extractor is just converting the datatype. Since the PLY files has its own coordinate system, the LAS files remains in the same origin. The PLY files can be transformed to gantry coordinate system.

[dlebauer]

@solmazhajmohammadi how do you currently perform the subsetting? Can you add the conversion to the gantry coordinate system?

[solmazhajmohammadi]

I think this part is handle in zongyang's extractor.

[dlebauer]

@ZongyangLi can you point to where the point cloud subsetting is performed?

[ZongyangLi]

@dlebauer @solmazhajmohammadi I do not have a subsetting extractor, as our meeting last Friday, it would be really helpful if I could get a correct subsetting plot level point cloud.

[dlebauer]

@ZongyangLi To do this we will need to have the las files in the gantry coordinate system. Can you implement this?

[ZongyangLi]

@dlebauer Sorry for the delay of replying, I was doing some initial testing on this.

I could have a try, but I even have no idea how to open las file, and do not visualiz a las file yet, it will take me times to dig into this.

Before I start this, I have some issue need to be confirm. @dlebauer @solmazhajmohammadi

1. What's actually this ply2las extractor doing?

   • From @solmazhajmohammadi 's comment, this extractor is just converting the datatype. So is it merging two ply files into one las file without any coordinate transfer? They are still coordinates in their own axis, it's still the same in the two source ply files.
   • If so, why we need this las file rather than one ply file made up with two ply files' point cloud, since no coordinates converted.
   • If so, instead of using las files, I would prefer to use two-side's ply file as input.

2. So the next implementation for me is 'to create new plot level ply files in the gantry coordinate system', is that correct? If so, from the very initial testing, I just have two issues now:

   • In one scan, there are two ply files, let's say 'west ply' and 'east ply'. Here are some visualization with two plys, they are east-ply, west-ply, two-side-ply: It seems to me that different ply have different 'interest', it means east-ply capture more point from west side. At the same time, it has a little bit shift between this two plys. What's the criterion of making some shift to make it merged well?
   • What's the criterion of merging two scan with little overlap? option 1, crop part of ply, option 2, remain all the points.

[solmazhajmohammadi]

@ZongyangLi PLY2LAS extractor convert the ply files to binary las files, las files are way smaller than ply files. There is extra part to the extractor, which merges the west and east LAS files. Merging the files doesnot need a coordinate transformation, since west and east ply files are in the same coordinate system. For transformation: I did a quick search, for the LAS files, libLAS library with using "las2las" command will do the transformation. Didn't have time to further install and try the library. but I do agree the ply file transformation would be more straightforward.

In this particular example that you have shared, I dont think that the difference in "interest" depends on the sensor. For west scanner, the plants are blocking the ground and shorter plants, so the the west scanner would see less points compare to east scanner. The offset between two ply files are due to temperature change. If I remember correctly this issue will be investigate for the next year release.

[dlebauer]

@ZongyangLi will:

• use point cloud origin to transform ply clouds to lat / lon las
• subset with bounding boxes.
• document errors related to the temperature, offset, etc. in extractor README
• keep all of the points. Can you label each point with the camera source (l/r)?

please ask @solmazhajmohammadi and @yanliu-chn if you need help.

[max-zilla]

@solmazhajmohammadi so i think we want one more transformation.

for the ply2las, we need to translate the PLY coordinates to lat/long coordinates. Then we can:

• create a merged LAS file in lat/long coordinates instead of point cloud coordinates (using point cloud origin)
• update plant_height extractor that @ZongyangLi wrote to subset the LAS files (if possible) by plot so we can push traits to BETYdb by plot

the heightmap extractor can still use PLY for now since that is separate.

[SolmazHajmohammadi-LemnaTec]

@max-zilla this transformation would be the pointcloud origin offsets, that we initially used for heightmap extractor(PCO values). Adding the pointcloud origin offset to the points in the ply files would transform it to the gantry coordinate system. From there would be applying the same gantry to gps transformation.

[dlebauer]

Here are some examples of what I had in mind

Clipping las files w/ bounding box

pdal

pdal translate --filters.crop.polygon="POLYGON(WKT FORMAT)" input.las plotname.las

from pdal translate https://www.pdal.io/apps/translate.html#example-1

lastools las2las

has -clip_to_bounding_box and -keep_xy arguments

https://www.cs.unc.edu/~isenburg/lastools/download/las2las_README.txt

Labeling points with source file

The goal of this is that - because the point clouds are not aligned, a user can differentiate between points that came from a particular (left or right) laser or a particular scan across the field.

The LAS 1.4 specification LAS_1_4_r13.pdf defines 'file source id' that can be an integer between 1 and 65k.

The lasmerge function does have an argument --set-point-source and lassplit allows splitting on this value, e.g. using -keep_point_source 3.

• A simple convention like 1=L and 2=R would distinguish points collected by the L vs R laser.
• If we are going to merge across overlapping scans, keeping L odd and R even would be sufficient (auto-incrementing with each scan).

[ZongyangLi]

@dlebauer I'm sorry that I was thinking this is a long term task that requires for a plot level subsetting LAS file. So for now it's clear that the task is to create a merged LAS with two source ply file without any clipping operations, and with geo-reference in it.

I tried to find some examples of georeferencing LAS file, such as liblas, laspy, pdal. It seems to me that I should create a VLR file store the geo-reference. There are some examples about writing new las files, but seldom of them describe how to input a specific bounding box like that in gdal. Could any of you give me some examples of how it works? Forgive me I am really not familiar with this.

[dlebauer]

@ZongyangLi thanks for checking this out. I am not sure if the bounding box is the best place to start - once you know how the [x,y,z] in the las files translate to the gantry [x,y,z], I imagine it should be possible to translate each [x,y,z] to [lon,lat,elevation] with the gantry --> latlon equations in the documentation https://terraref.gitbooks.io/terraref-documentation/content/user/geospatial-information.html.

It seems like generating a VLR file that defines the projection would be the preferred path, but I can't tell. las2las has the argument --point-translate arg which also looks promising. @jterstriep or @solmazhajmohammadi or @yanliu-chn are you familiar with these tools?

[ZongyangLi]

@dlebauer if someone can confirm the las2las argument --point-translate arg suit for this case, I will do such a [x,y,z] to [lon,lat, elevation] translating.

From my further investigate, LAS 1.4 uses Well Known Text for storing coordinate system information. I found such a XML file that maybe have some parameter for this translate: { "pipeline": [ { "type" : "readers.las", "filename" : "input.las" }, { "type" : "writers.las", "a_srs": "EPSG:4326", "filename" : "output.las" } ] } I was thinking it first point out the a_srs is 'EPSG:4326' then assign the offsets and scales to all the points.

[dlebauer]

@jterstriep can you confirm?

[max-zilla]

@ZongyangLi @solmazhajmohammadi Just wanted to ping on this to see if you guys have had a chance to talk.

Zongyang, I'm not sure about las2las. I talked with @jterstriep here about this topic and he has some suggestions on how we can improve but probably not for November. Short term, the goal is just LAS files that are georeferenced. Seems like we're still missing the actual conversion piece, I'm hoping Solmaz might be able to help there.

For next year, having the PLY files from Windows be georeferenced properly would be ideal. We also talked about pros/cons of having a full field point cloud product and how it might be used vs. keeping individual scans and clipping them to plots on-demand.

[solmazhajmohammadi]

Two suggestion to geolocate the LAS files:

• reading ply files prior to conversion to LAS files, and applying the transformation to PLY files. Then convert the files. This would be fairly straightforward.
• or either using las2las --point-translate or -translate_x/ -translate_y/ -translate_z I have not tried the XML version that @ZongyangLi suggested.

[max-zilla]

@solmazhajmohammadi the first option (read PLY and apply transformation) would be fine. do you have the code to do that?

[solmazhajmohammadi]

@max-zilla @ZongyangLi this peace of code is applying the transformation to get the PLY files in the Gantry Coordinate system: https://github.com/solmazhajmohammadi/heightmap/blob/master/test/main.cpp The rest of process is similar to this to change to lat/lon.

[max-zilla]

For now, used @ZongyangLi code to convert LAS file coordinates for minimal code modification: https://github.com/terraref/extractors-3dscanner/pull/11

[max-zilla]

@ZongyangLi FYI following up from call we just had, removed conversion piece: https://github.com/terraref/extractors-3dscanner/commit/64da04208f445ccf08f728ac8bd667401789782b

[craig-willis]

Stale issue. Will create new review issue for 2018.