Re: offset in las2txt and txt2las

[Martin Isenburg]

Hello Andrew,

by default txt2las uses an automatically computed offset to avoid an
integer overflow of the raw XYZ integers that are stored in the LAS
file when the Northing and the Easting are really large numbers. The
way the offset is chosen is the nearest full 100000 multiple of the
first x and y coordinate in the file, hence 200000 and 6600000 for
your sample_points.txt where the first point is "220022.87 6623000.13
486.35".

To "disable" this "smart offset" mechanism you can simply provide your
own offset and requesting it to be 0 0 0 as shown in the command
below.

txt2las -i sample_points.txt -o sample_points.las -set_offset 0 0 0

But be advised that without proper offsets you may run into an integer
overflow. For example, if your data was requested to have a millimeter
resolution (i.e. a scale of 0.001 0.001 0.001) and your first point
was "220022.871 6623000.133 486.352" then the resulting raw Y
coordinate would be 6623000133, which is too big to be stored with 32
bits.

Regards,

Martin @rapidlasso

On Dec 16, 5:53 pm, Andrew Goodwin <newcastlemu...@gmail.com> wrote:
> Part of our workflow consists of converting a text file to a .las file,
> then after some processing, converting it back to text again. When we
> output the text files at the end of this process we use the "-parse XYZ"
> option of las2txt to obtain the "unscaled, raw LAS integer coordinates".
>
> To illustrate this process I started with the following co-ordinates in a
> file called "sample_points.txt".
>
> 220022.87 6623000.13 486.35
> 220020.11 6623000.06 486.34
> 220020.74 6623000.57 486.37
> 220021.34 6623001.07 486.38
> 220021.92 6623001.55 486.39
> 220021.80 6623001.50 486.37
>
> Then ran the following commands in sequence:
>
> txt2las -parse xyz -i sample_points.txt -o sample_points.las
> las2txt -parse XYZ -i sample_points.las -o sample_points_v2.txt
>
> What I was expecting to see in the file "sample_points_v2.txt" was:
>
> 22002287 662300013 48635
> 22002011 662300006 48634
> 22002074 662300057 48637
> 22002134 662300107 48638
> 22002192 662300155 48639
> 22002180 662300150 48637
>
> However what I actually get is:
>
> 2002287 2300013 48635
> 2002011 2300006 48634
> 2002074 2300057 48637
> 2002134 2300107 48638
> 2002192 2300155 48639
> 2002180 2300150 48637
>
> The "X" column has values that are 20000000 less than I expected and the
> "Y" column has values 660000000 less than I expected. I suspect this has
> something to do with the "-set_offset" in txt2las, however as you can see
> from the command above, I didn't use this option.
>
> When I run lasinfo on the intermediate file "sample_points.las" one of the
> lines says: "offset x y z: 200000 6600000 0". This would suggest that
> txt2las has assumed an offset and written it into the header
> of "sample_points.las", but I don't understand how this works and why my
> output file "sample_points_v2.txt" did not have the values I expected. Any
> information about how these offset values are selected and applied would be
> greatly appreciated.
>
> I have attached files containing the sample data file and commands I
> used. I'm using the latest version of LAStools for these tests (December
> 12th, 2012 release).
>
> Regards
> Andrew Goodwin
>
> Environmental Engineer
> Umwelt (Australia) Pty Limitedhttp://www.umwelt.com.au/
>
>  sample_points.txt
> < 1KViewDownload
>
>  commands.txt
> < 1KViewDownload