We are uploading 3D models via the Rest API and would like to use the optional position property (long/lat/height) to correctly geo locate the model on the globe. The documentation for this property states;
“this value is ignored if the source data already contains georeferencing information”
Is there any detailed documentation available regarding what sort of file formats and ‘georeferencing’ information is being referred to here?
Hello,
Thanks for your question. I’d like to ask a couple questions that will help me get you the information you need:
Here is an example of how 3D models can be georeferenced via a KML file that is uploaded alongside the model: Create 3D Tiles from KML/COLLADA with Per-Building Data – Cesium
Thanks,
Matt
Hi Matt,
Thanks for your reply.
Currently we are mostly uploading LAS and OBJ files. For the LAS files it’s my understanding that the georeferencing information is a standard inclusion in the LAS file header. However, some of our LAS files come out as georeferenced 3D Tiles, and others do not. I will send you a message with example ion Asset id’s. I also have uploaded an OBJ with a metadata file, but this seems to be ignored. I’ll also send you an example of this.
I haven’t yet tried supplying the optional position property in the REST API as I wanted to understand what files would (or wouldn’t) require me to do that.
I tried following the KML example in the link by adding a .kml file alongside my OBJ, but again it didn’t seem to do anything. I’ll include a sample of this in the message.
Hi,
Thanks very much for sending over the data. For the 3D models, how is the 3D data being collected/generated? Is it possible to export as a dae, gltf, or glb file from the software you’re using?
If I understand correctly what you’re looking to achieve, here are some steps that would allow you to use the KML/COLLADA option in ion:
.dae) file.Sample KML file:
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<name>Name of Feature</name>
<Model>
<Link>
<href>filename.dae</href>
</Link>
<Location>
<longitude>xxx.xxx</longitude>
<latitude>xxx.xxx</latitude>
<altitude>xxx</altitude>
</Location>
<Orientation>
<heading>xxx</heading>
<tilt>xxx</tilt>
<roll>xxx</roll>
</Orientation>
<Scale>
<x>1</x>
<y>1</y>
<z>1</z>
</Scale>
</Model>
</Placemark>
We’re taking a look at the LAS files as well and will get back to you as soon as possible.
Thanks,
Matt
Hello again,
I took a look at the LAZ files you provided, running pdal info on each of them. It seems that one of them specifies a CRS in its header (EPSG:4326) but the other doesn’t, which is why only one of them gets georeferenced properly.
Do you know the CRS for the data that is missing a CRS in its header? If so, you might be able to set it manually using a tool like pdal or LAStools.
With pdal, the command would be:
pdal translate path/to/input/file.laz desired/path/to/output/file.laz reprojection --filters.reprojection.in_srs="EPSG:4326" --filters.reprojection.out_srs="EPSG:4326"
And with LAStools, the command would be:
las2las -i path/to/input/file.laz -epsg 4326 -target_epsg 4326 -o desired/path/to/input/file.laz
Note that EPSG:4326 is not correct for that data. I just included it there as an example.
Matt
Hi Matt,
Thanks for this additional information. Are you saying that if I provide a KML file (using the format in the example above) this will feed all this information (including orientation) into the Cesium tiling pipeline? But this will only work when using .dae COLLADA?
Is there a way to do this with .obj or .glb?
Hey Matt,
This all makes sense. I will make sure that we have CRS information specified in the header for all LAS/LAZ files going forward.
Hi,
Yes, if you upload a KML file in that format alongside COLLADA data, it will feed it into the tiling pipeline and place the data at that location on the globe. Using this approach to manually georeference geometry is somewhat nonstandard, but it will work. Typically, the KML file is generated by whatever software generates the source data itself.
The reason we support KML/COLLADA specifically is because that combination of files can be exported from software like CityEngine, Rhino, 3DCityDB, SketchUp, and others. To my knowledge, we don’t support file types other than COLLADA (dae) for this workflow, but let me check my information on this and get back to you.
I would recommend trying this approach with a minimal example to see if it works for you. Here is an example KML/COLLADA combination:
cube.zip (1.8 KB)
Below are the ion settings you would use with these. Once they finish tiling, ensure the asset is selected under My Assets and click Open complete code example at the bottom of the panel on the right.
Hi again,
Would you mind sharing the name of the software that generated the data? I’m checking with a colleague on this, and knowing the source of the data would help us understand if there are alternatives we can suggest.
Thanks,
Matt
I’m having to revisit this issue. We have found that different software will populate different levels of SRS/CRS information in the VLR’s in the header of a LAS file. We want to make sure these headers are written consistently so they are interpreted correctly by Cesium. To do this we need to understand specifically which of these VLR’s Cesium is using. I’ve added links to an extract of the LAS header from two examples of the same model so you can see what I’m referring to.
https://www.dropbox.com/s/blptpt1p7d3axuu/laz_header_original.txt?dl=0
https://www.dropbox.com/s/tzlap2it627p57y/laz_header_updated.txt?dl=0
Our point cloud tiler first checks for a WKT VLR (record ID = 2112). If a WKT VLR doesn’t exist, the tiler manually checks for GeoTIFF keys (record IDs = 34735, 34736, 34737) to reconstruct the WKT.
See this documentation for more on these VLRs: http://www.asprs.org/a/society/committees/standards/LAS_1_4_r12.pdf
Here is some more information on WKT vs. GeoTIFF keys for point clouds: LAS Reading and Writing with PDAL — pdal.io
Was this the information you needed? Please let us know.
