Switch place on x and y-coordinates in las-file

[Mattias Nyström]

I would like to switch place on x and y in some las-files (coordinate system Sweref99TM, epsg 3006), but I can’t get it to work with las2las and the parameter –switch_x_y. It does something, but does not switch place on the two (x and y)… I can do it by first create a txt-file and then a las-file again from the txt-file, but I thought the flag –switch_x_y would do the job for me… Have I misunderstood the meaning of that parameter?

[Terje Mathisen]

I was going to suggest using the txt route but I see you've already
tested that and it works. :-)

With the recent addition of LAS header propagation via an empty copy and
a following lasmerge the txt method will allow you to get back exactly
what you started with, but I didn't even realize that there was a
-switch_x_y flag.

Good luck!

Terje
PS. What sort of LAS/LAZ file did you get where Lantmäteriet have
managed to mess up the coordinate order?
>
> --
> Download LAStools at
> http://lastools.org
> http://rapidlasso.com
> Be social with LAStools at
> http://facebook.com/LAStools
> http://twitter.com/LAStools
> http://linkedin.com/groups/LAStools-4408378
> Manage your settings at
> http://groups.google.com/group/lastools/subscribe


--
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Mattias Nyström]

It's not Lantmäteriet messing up the coordinates or in someway it is... I'm using Gtrans (Lantmäteriets software) to transform old coordinate systems and elevation models into the recent Sweref99TM RH2000 and the Gtrans software works the opposite way with x and y... x is north and y is east in that software and when i had created all las-files i found that out... and i had removed all files before I realized that. It would have been very easy to just switch place on x and y with that flag, but I have now done it using the las2txt and then txt2las way... but still it would be interesting to know what the flag switch_x_y does...

[Martin Isenburg]

Hello Mattias,

the streaming on-the-fly transform '-switch_x_y' only switches the raw
integers fields X and Y of every point record. It should really be
called '-switch_X_Y' and likely I will change this soon. This
'-switch_X_Y' only produces the desired result in your case if the
x_offset and the y_offset as well as the x_scale_factor and the
ynot_scale_factor in the header of the LAS / LAZ file are identical.
If they are not you will need to switch those too. Currently this has
to be done manually by first (!) using lasinfo's '-set_offset x y z'.
I just realize that this is one example where poorly chosen (aka ugly)
scale factors and offsets like these ones here that I just came
across:
[...]
scale factor x y z: 0.000000699800645 0.000000467563925 0.000000105423387
offset x y z: 7860029.2694503004 904315.10862596892 636.79500000000007
[...]
can be really quite annoying.

Here the workflow

(1) check the scale factor and offsets with lasinfo

D:\lastools\bin>lasinfo -i in.laz
[...]
scale factor x y z: 0.01 0.01 0.01
offset x y z: 200000 6100000 0
min x y z: 277750.00 6122250.00 42.21
max x y z: 277999.99 6122499.99 64.35
[...]
reporting minimum and maximum for all LAS point record entries ...
X 7775000 7799999
Y 2225000 2249999
Z 4221 6435
[...]

(2) switch those that need switching

D:\lastools\bin>lasinfo -i in.laz -set_offset 6100000 200000 0 -nh -nc

(3) verify they were changed with lasinfo. the warnings are expected

D:\lastools\bin>lasinfo -i in.laz
[...]
scale factor x y z: 0.01 0.01 0.01
offset x y z: 6100000 200000 0
min x y z: 277750.00 6122250.00 42.21
max x y z: 277999.99 6122499.99 64.35
[...]
reporting minimum and maximum for all LAS point record entries ...
X 7775000 7799999
Y 2225000 2249999
Z 4221 6435
[...]
WARNING: 277573 points outside of header bounding box
[...]
real max x larger than header max x by 5900000.000000
real min y smaller than header min y by 5900000.000000
[...]

(4) do the switch of X and Y

D:\lastools\bin>las2las -i in.laz -switch_x_y -o out.laz

(5) verify the final result

D:\lastools\bin>lasinfo -i out.laz
[...]
scale factor x y z: 0.01 0.01 0.01
offset x y z: 6100000 200000 0
min x y z: 6122250.00 277750.00 42.21
max x y z: 6122499.99 277999.99 64.35
[...]
reporting minimum and maximum for all LAS point record entries ...
X 2225000 2249999
Y 7775000 7799999
Z 4221 6435
[...]

(6) scream "Yeah, I did it!!!". (-;

Cheers,

Martin @rapidlasso

--
http://rapidlasso.com - fast tools to switch your LiDARs

[Mattias Nyström]

Hi Martin, 

Thanks for the explanation. Would it be an option to add a flag that makes this automatically (changing offset as well)? There are 320 files that I want to do this for so I can't manually do for every file. However, I have solved it by exporting to txt and created las again.

Cheers,

Mattias Nyström

[Terje Mathisen]

What all that below tells me would be that in this particular situation
it is actually better to go via plain txt, since that format carries no
meta-information at all. :-)

You should also avoid using lasmerge to bring forward the headers, since
the bounding box will be wrong after flipping, right?

Something like this should work:
for %f in (*.laz) do las2txt -i %f -parse xyzainrcupedRGB - stdout |
txt2las -stdin -parse yxzainrcupedRGB -o %f_flipped.laz

The parse strings could be shortened and the pipe symbol probably means
that the inner command should be put in a separate .BAT file.

Terje

[Martin Isenburg]

Hello Mattias,

in this case simply try to find any identical offset that works for
both x and y (i.e. without making the integer X and Y coordinates
leave the range of a 32 bit integer). An offset of zero will usually
work for most projected airborne LiDAR points if your scaling factors
are centimeters. But sometimes 3000000 may be a better choice. Then do
the following:

las2las -i *.laz ^
-reoffset 0 0 0 ^
-switch_x_y ^
-odix _switch -olaz

or (but not and !!!) the following:

las2las -i *.laz ^
-reoffset 3000000 3000000 0 ^
-switch_x_y ^
-odix _switch -olaz

and (optionally) have this followed by an auto_reoffset (i.e. to move
the integer X and Y coordinates closer to zero and farther from the
range limits of a 32 bit integer):

las2las -i *_switch.laz ^
-auto_reoffset ^
-ocut 7 -odix _auto -olaz

Regards,

Martin @rapidlasso