Hello, I’m currently working with bathymetry data as .LAZ files. I’m using the REST api as provided in the github repository to upload each file individually. When providing the type:3DTILES, sourcetype:POINT_CLOUD, I also give it a position as to avoid having to do it manually in the GUI.
However, I’m finding that when doing this the tileset location in the GUI is completely wrong. Attached are some snapshots showing that the uploads are successful, but when providing the correct position through the REST api, the point cloud is found floating high in the North Atlantic. If this same position is entered in the cesium GUI, it shows up exactly where expected. Another test was providing [0, 0, 0] as a position through the REST api, and again the point cloud is found floating high above Northern Africa. If the position attribute is commented out, the origin is in fact [0, 0, ~17]… Is there some correctively offset that I’m missing?
The original data was in UTM 14N and converted into a .LAZ file, but the position location provided are in EPSG:4326 WGS 84. Thanks @omar
We’ve found what our issue was! As stated in the docs, the position attribute of the POINT_CLOUD sourcetype is to be populated with [lat, lon, height], where lat/lon are in WGS84 EPSG 4326 format, and height in meters. Because our point clouds are in UTM and farther away from the zone’s origin, the values for easting and northing are quite large (1e5 - 1e6), and of course, in meters. Unaware that Cesium uses meters, we were providing the correct position in lat/lon decimal degrees through the REST api, but the point cloud ended up being very far away from the intended origin because its units are in meters (e.g., it added the easting and northing to the lat/lon origin). Lesson learned: if georeference information is not provided with the LAS file and you do provide a position using the REST api, the point cloud should be normalized around that origin, but in meters.
Now knowing this, I hope that having it documented here will help others in the future (and potentially make its way in the official docs somewhere). I also noticed that when uploading the same file through the GUI and the REST api with position data gives inconsistent results, making me believe that internally the “correct position” is calculated differently for each uploading method. Through the GUI the file is placed in Northern Atlantic (thus utilizing some georeference information), but can then be corrected using the AdjustTile Location feature. But, when using those same coordinates within the position attribute of the REST api, the file still ends up in the Northern Atlantic, which is not really the correct location. I think for consistency’s sake it might be easier if the REST api took the file, created the 3DTile, located it, and then applied the correction the same way AdjustTile Location does it.
But, hope this helps anyone in the future! Cheers.
1 Like
