4

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?

6

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.

  • @Hobu Thanks again for the very informative explanation. I guess my reasoning for asking this question, which perhaps I should have included in my question, is whether placing the coordinate system false E/N as an LAS offset is common practice in the industry or in COTS software, such as CloudPro. I typically see no offset when one is not required, however, I have seen instances where an offset is not necessary, and the coordinate system's false E/N is used. – Barbarossa Mar 21 '16 at 20:24
  • 2
    It doesn't really matter as long as it isn't going to overflow. Some softwares maintain a min(dimension) offset approach, others leave it 0.00, and others do mid(dimension). I would say I see the min(dimension) most commonly, but there are really all kinds. – Howard Butler Mar 21 '16 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.