Extra Bytes not being read into tilesets during build.

[tlcrowell]

Trying to build a tileset from a laz file that includes an Extra Bytes field called treeID. When looking at the point values using pdal we're able to see that the field is there.

(pdal) [ec2-user@ip-172-31-12-146 input]$ pdal info extractPD_403500-000000_3316500-000000.laz -p 0 { "file_size": 130073036, "filename": "extractPD_403500-000000_3316500-000000.laz", "now": "2020-05-02T14:01:18+0000", "pdal_version": "2.1.0 (git-version: 46c336)", "points": { "point": { "Blue": 28815, "ClassFlags": 0, "Classification": 0, "EdgeOfFlightLine": 0, "GpsTime": 573137.4354, "Green": 30600, "Intensity": 70, "NumberOfReturns": 2, "PointId": 0, "PointSourceId": 2, "Red": 25245, "ReturnNumber": 2, "ScanAngleRank": 0, "ScanChannel": 0, "ScanDirectionFlag": 0, "UserData": 0, "X": 403655.95, "Y": 3316985.41, "Z": -0.17, "treeID": -1 } }, "reader": "readers.las"

We then run a build to generate the tileset and the build indicates it recognizes the treeID dimension and reports it as storing it.

Scanning input Resolving [file]: /lidar/input/* ... Resolved to 1 paths. 1/1: /lidar/input/extractPD_403500-000000_3316500-000000.laz

Entwine Version: 2.1.0 EPT Version: 1.0.0

Metadata: SRS: EPSG:4978 Bounds: [(-385755, -5516207, 3167822), (-385215, -5515530, 3168487)] Cube: [(-385825, -5516209, 3167815), (-385145, -5515529, 3168495)] Reprojection: EPSG:26915 (by default) -> EPSG:4978 Storing dimensions: [ X:int32, Y:int32, Z:int32, Intensity:uint16, ReturnNumber:uint8, NumberOfReturns:uint8, ScanDirectionFlag:uint8, EdgeOfFlightLine:uint8, Classification:uint8, ScanAngleRank:float, UserData:uint8, PointSourceId:uint16, GpsTime:double, Red:uint16, Green:uint16, Blue:uint16, ScanChannel:uint8, ClassFlags:uint8, treeID:double, OriginId:uint32 ]

The info listing of the tileset laz file does not include this attribute though.

(pdal) [ec2-user@ip-172-31-12-146 tileset]$ pdal info /lidar/tileset/ept-data/5-24-7-19.laz -p 0 { "file_size": 158478, "filename": "/lidar/tileset/ept-data/5-24-7-19.laz", "now": "2020-05-02T04:09:06+0000", "pdal_version": "2.1.0 (git-version: 46c336)", "points": { "point": { "Blue": 28560, "Classification": 2, "EdgeOfFlightLine": 0, "GpsTime": 491832.3944, "Green": 30855, "Intensity": 62, "NumberOfReturns": 1, "PointId": 0, "PointSourceId": 2, "Red": 31875, "ReturnNumber": 1, "ScanAngleRank": 0, "ScanDirectionFlag": 0, "UserData": 0, "X": -385293.8, "Y": -5516060.05, "Z": 3168219.28 } }, "reader": "readers.las" }

[mccarthyryanc]

Try having pdal read the EPT dataset directly:

pdal info --schema ept:///lidar/tileset/

The base LAZ format used by entwine is 1.2, and pdal needs flags, use_eb_vlr, to recognize extra bytes for versions before 1.4. But if you tell pdal that your dataset is EPT explicitly, it will read the extra bytes.

[tlcrowell]

Ok, it does show up in the dimensions there. Ultimately I'm trying to have this value populated in a cesium tileset and I understand based on an answer you previously gave me that it should come through automatically. Is there a way to validate that it's making it into the tileset generated for cesium? CesiumJS isn't finding it. I know we may have transitioned into more of a how to issue so if another forum is more appropriate I can move this.

[mccarthyryanc]

@tlcrowell , I think you need two steps for Cesium 3D Tiles: first a build, then a convert. Do you have the output of the convert step?

[tlcrowell]

I do. I'm trying to work out viewing the results of the convert now. Had stopped once I didn't see the value in the ept data.

[tlcrowell]

@mccarthyryanc Ok, so I've confirmed that points in the cesium tileset after the convert do not include the treeID that is in the ept points. Is there something explicit that needs to be done to include that value?

[mccarthyryanc]

@tlcrowell, haven't worked with cesium tilesets and had to dig into the source. But is looks like entwine only supports converting point position, color, and normals. The 3D Tile spec, section 10.4: Per-Point Properties, does support additional attributes. @hobu or @connormanning would have to comment, but I think this would have to be a feature request.

[connormanning]

This should work properly with viewer.copc.io.