Re: [LAStools] Using las2las with -translate_x -translate_y options

[Martin Isenburg]

Hello Ranjith,

The quick answer is: add the '-reoffset 0 0 0' command to the las2las
command line.

But this an excellent question and deserves a longer answer. What you
are seeing is an integer overflow due to the large translation. If you
know about the internals of the LAS format you know that the xyz
coordinate are stored as XYZ integers that are computed this way:

x = X * x_scale_factor + x_offset;
y = Y * y_scale_factor + y_offset;
z = Z * z_scale_factor + z_offset;

Where the scale factors and the offsets are defined in the header (see
lasinfo output). So in your example we have

x_offset = 698309.0
y_offset = 3322339.0
z_offset = 0.0

x_scale_factor = 0.001
y_scale_factor = 0.001
z_scale_factor = 0.001

the integer range of X, for example, is 3353565 to 3473543 (see
lasinfo output) so with the calculation above we can compute the min
and the max of x with

min_x = 3353565 * 0.001 + 698309.0 = 701662.565
max_x = 3473543 * 0.001 + 698309.0 = 701782.543

which is exactly what is reported for the bounding box in the header
(since '-repair' computes it like that).

The '-translate_x' and '-translate_y' transforms are implemented as
transform filters that are applied after reading the header. That
works fine for smaller translates. But if you do a huge translation
then you get in conflict with the offset. Why is that offset even
there? Well, in order to store an origin near where the points are so
their coordinates can be compactly expressed with 32 bit integers. But
if you move the points by a huge distance you must also move the
offset. Otherwise the point coordinates run into danger of no longer
being able to be expressed with 32 bit integers as each coordinate has
now to bridge the huge relative distance to the offset that is still
centered at (698309.0 / 3322339.0 / 0.0) while all the points are now
near (0.0 / 0.0 / 0.0). You can see that in the lasinfo output of
tile_1.las where the integer range of X is now -698309000 to
-698189022 whereas the integers for Y wrapped over into the positive.
Moving the origin to (0.0 / 0.0 / 0.0) via '-reoffset' at the same
time as translating the coordinates prevents the integer coordinates
from overflowing.

Anyone still with me? (-:

Regards,

Martin @rapidlasso

On Fri, Aug 10, 2012 at 3:29 PM, RG <ranjith.gop...@gmail.com> wrote:
> Hi all,
>
> I am working on a project where I have to remove all geo-location
> co-ordiniate information from given lidar plots. I am using "las2las
> -translate_x {value} -translate_y {value}" for this. It works for some
> files, but does not for some others. This is only for the y co-ordinates.
> Attached is a las file for which it does not work. Also, in the attached
> word-doc, I have given all the steps that I have taken. Basically, I am
> finding the minimum-x and minimum-y using lasinfo and then using that
> information for the las2las translate_x command. I hope you will be able to
> reproduce the problem using the word-doc.
>
> In the word-doc, please look at the boldfaced parts. Also, as the
> convenstion is, the italics part is the output of the tool, while the
> non-italics is what I had typed in.
>
> I am using lastools, downloaded from
> http://www.cs.unc.edu/~isenburg/lastools/download/lastools.zip on 9th
> August, 2012 (just yesterday).
>
> Any advice on this would be appreciated.
> Thanks,
> Ranjith.