Tiling LAS files from UTM zone 43N

Edit: This originally started at Cesium point tile rendering with deckgl - #8 , but it seems like the underlying issue is about the coordinate reference systems of LAS files


Thanks for such a detailed reply. Some more info from my side which may be helpful:

  1. My las files are of older version ie they dont have any CRS information, though I know they belong to UTM zone 43N.

  2. I came to know that cesium uses EPSG 4978, So if I generate cesium compatible pnts files, with projection to 4978, using a software like py3dtiles, and then render on cesium ion. I observe that data is rendered at correct geo location, but not aligned in terms of height,and sort of hanging in air.

I would try to provide las file here, but seems .las extension is not allowed here.

Following zip output of lasinfo64:

output_173.zip (1.2 KB)

I moved the last post with the details about the LAS file into the “Cesium ion” section. Hopefully, someone can provide additional information about how to handle a LAS file with this reference system.

(By the way: It should be possible to simply pack the LAS into a ZIP, and then attach the ZIP here. But maybe the lasinfo output will already be enough to provide further guidance)

1 Like

Hi @mghildiy

For tiling data we recommend uploading the data with the local coordinate system and either rely on the projection information in the LAS file, or manually adjusting the tileset after tiling with the Adjust tileset location option. Ion tiling works best with the data is centered around a local origin.

When you are viewing this data and it appears floating, what terrain are you using? For example there are many places where the actual world terrain does not line up with the ellipsoid, so if you are only using the ellipsoid for the terrain, real world data can appear to float above it.

If you do have an asset that you think is positioined incorrectly after tiling, please let us know the asset id so we can investigate it further.

@mdc9001 Some additional context is in the linked thread, e.g. at Cesium point tile rendering with deckgl - #6 by mghildiy , including the asset ID and what I assume to be the result that was generated and downloaded from ion.

I uploaded that data (as 3D Tiles) on my account and had a look, using “Adjust tileset location”: The data seems to be floating waaay above the ellipsoid, and also does not seem to be rotated properly (even if it was at the ground at this point). Also, the center (i.e. the coordinate axes that are displayed in the location editor) seem to be far away from the actual data.

Some observations:

  • The tileset does not have a root transform
  • It contains oriented bounding boxes
  • The center of the root bounding box is somewhere at (longitude, latitude, height) = (70, 0.1, 400000) or so (I’d have to check the exact numbers - in any case, it was something that doesn’t make sense…)
  • The tileset refers to PNTS files

For me this suggests that a certain geographical position is encoded in the actual POSITION attribute of the PNTS files. And while it’s theoretically possible to define a root.transform that basically “cancels out” these wrong positions, it feels like a quirky workaround. As you said: Preferably, the data inside the PNTS should be relative to a local origin.

But I’m not sure whether there is an easy way to achieve that. Maybe there is some sort of LAS tool that allows assigning a certain CRS that can be picked up by ion, or even “preprocessing” the LAS so that it is at the local origin…? (I could probably hand-craft a tool for that, based on some local LAS library that I’ve been pondering with, but maybe there is a canonical approach for that…)

Also, the center (i.e. the coordinate axes that are displayed in the location editor) seem to be far away from the actual data .

This sounds like the source data was not located around the origin and was already pre-positioned in some coordinate system.

You can use las2las from lastools to add in the projection information if the file is missing it. If you upload a LAS file with projection information Cesium ion will handle the reprojection during tiling so that your data ends up in the correct location after tiling.

Please let us know if using las2las works for you.

Ok, I would give it a try. Just to confirm, which CRS I need to add to it for it to align correctly in cesium ion.

which CRS I need to add to it for it to align correctly in cesium ion.

That depends on what coordinate system your data is defined in. You mentioned that it was in UTM zone 43N earlier.

If you don’t know the coordinate system you can always upload without it and the use the Adjust tileset location option to position it correctly.

1 Like

So with CRS information added(ESPG 32643), I uploaded updated las to ion, and see it rendered correctly in terms of geo location. But height is still not aligned well. Is that expected?
I have uploaded las info for updated las.
lasinfo.zip (1.3 KB)

There are basically two sources of the error for a “wrong height”:

  • The source data of the model may contain the “wrong height”
  • The data in which context the model is displayed has the “wrong height”

(And the term is written in quotes, because the height is always “wrong” in one way or another - see What is the shape of the earth? for details)

So the first question is:

When you tile that data with the additional CRS information, can you still use the “Adjust Tileset Location” functionality? If this is still possible then you can adjust the height there.

Otherwise:

Are you using a certain terrain model for the visualization, like Cesium.Terrain.fromWorldTerrain?

Otherwise:

You can still adjust the tileset location (height) manually, by assigning the proper tileset.modelMatrix. This is similar to what I wrote in the other thread - fetails can be discussed when necessary.