How does the offset values of LAS files relate to their coordinate system?

Question

I have a conundrum concerning LiDAR data, the stored point offset, and the coordinate system.

I process large amounts of LAS data in TerraScan (TS), which sits on top of Microstation (MS). I receive LAS files that are created from raw data by CloudPro. Traditionally, when setting up a project, before importing points, I set the coordinate system up in TS, including any false easting/northing values. I typically set these values to that of whatever coordinate system I happen to be working in (e.g. For NAD83 Virginia South State Plane US_Foot, false_easting: 11482916.667, false_northing: 3280833.333).

I just started working on a dataset in NAD83 UTM 15N meters (false easting: 500000). I set the TS false easting, and began setting up the project. Unfortunately, after some investigation, the LAS files have an x,y,z offset (230247.299, 3550963.700, 0) that will not allow them to fit inside the bounds defined by the 500000m false easting. I understand this is due to MS's coordinate range of +/-2147484 of the defined coordinate origin x,y,z. I also understand that an LAS file's coordinates take the scale and offset into consideration. From the ASPRS specification:

X, Y, and Z offset: The offset fields should be used to set the overall offset for the point records. In general these numbers will be zero, but for certain cases the resolution of the point data may not be large enough for a given projection system. However, it should always be assumed that these numbers are used. So to scale a given X from the point record, take the point record X multiplied by the X scale factor, and then add the X offset.

This got me thinking, how (if any) does the offset of an LAS file relate to the coordinate system that it is projected to?

Answer 1

This got me thinking, how (if any) does the offset of an LAS file relate to the coordinate system that it is projected to?

They don't really relate to the coordinate system. The offset (in combination with the scale) are used to allow the XYZ values to be stored as 32-bit integers with enough precision to fit entirely within the box [−2,147,483,648, 2,147,483,647]. It is common to set the offset to the minimum value for the file/tile/dataset for each dimension, or the sometimes I will see the midpoint of each dimension. Many times the offset for each dimension will be the minimal value for a range of tiles. Any value is legitimate as long as it doesn't cause the data to overflow the range of the box when the stored integer is multiplied by the scale factor and added to the offset.

When you are creating LAS files, you should work to ensure that the scale factors represent measurement scale of the data (say 0.01 or 0.025) and not the highest possible precision available given the range of the box (like very tiny things such as 1.264142e-7). Over driving the precision has no real cost for uncompressed LAS, but it is very detrimental to compression like LAZ, where it essentially ends up adding incompressible noise. Martin Isenburg has written extensively on this topic in numerous venues.