Convert a point cloud from feet to metres

[James Carracher]

Hi all,

I know this question has been asked a few times, but I don't see a satisfactory answer. So please bear with me

I have a point cloud with the units being feet. I wish to change this so that it is metres. So basically change a coordinate of 10,10,10 to 3.04,3.04,3.04 

I can do this with las2las using the scale option. However, this does not always work as I get a las integer overflow a lot of the time.
WARNING: total of 143337824 overflows caused by '-scale_xyz 0.304800 0.304800 0.304800 '

Is there a way to directly change the units? I assume this needs to be able to update the offset in the LAZ header too?

I wish to be able to go the opposite direction as well (feet to metres). And I wish to avoid the need to know the coordinate system

Thanks

[Kirk Waters - NOAA Federal]

I suspect you need to add -auto_reoffset (or set your own offsets with -reoffset). I'm guessing that the current values in feet are very large and there is a large offset in the file already, but it's appropriate for feet and not meters. Your resulting values after subtracting the offset are too (probably negatively) to fit in an int32, which the LAS format requires.

Kirk Waters, PhD 

NOAA Office for Coastal Management

Applied Sciences Program      

coast.noaa.gov/digitalcoast

--
Download LAStools at
https://rapidlasso.de
Manage your settings at
https://groups.google.com/g/lastools/membership
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/c5cc9584-fa9b-4e41-b3a0-ec3d581b3085n%40googlegroups.com.

[Jochen Rapidlasso]

Hi James,

to change just the scaling you don't have to touch each point individually, this can simply and fast be achieved by setting the scale in your LAZ header.

Let's do a sample:

As input we create a textfile "in.txt" like

1000000.00 111111.11 10.00
1000010.01 222222.22 11.11
1000200.02 333333.33 12.22
1003000.03 444444.44 10.00

We push this into a LAZ file

    las2las64 -i in.txt -o tmp.laz -iparse xyz -rescale 0.01 0.01 0.01

and optimize to get a sample offset in our header as well

    lasoptimize64 -i tmp.laz

we have now:

point count:    4
scale x y z:    0.01 0.01 0.01
offset x y z:   1000000 100000 0
min x y z:      1000000.00 111111.11 10.00
max x y z:      1003000.03 444444.44 12.22
range x y z:    3000.03 333333.33 2.22

let's create a copy - just to have our original data as backup

    copy tmp.laz tmp_ft.laz

to change the scale in the header we use lasinfo64, our favorite tool to patch header data:

 
    lasinfo64 -i tmp_ft.laz -set_scale 0.00304 0.00304 0.00304 -set_offset 304000 30400 0

because we just changed the scale, and not the data, our header bounding box become invalid:
lasinfo tells this with some warnings:
   
WARNING: stored resolution of min_z not compatible with z_offset and z_scale_factor: 10
...
WARNING: real min z smaller than header min z by 6.960000
...

We fix this by a repair of the bounding box:

    lasinfo64 -i tmp_ft.laz -repair_bb

A final check to see if header is fine and without warnings:

    lasinfo64 -i tmp_ft.laz

scale x y z:    0.003 0.003 0.003
offset x y z:   1000000 100000 0
min x y z:      1000000.000 103377.777 3.040
max x y z:      1000912.009 204711.110 3.715
range x y z:    912.009 101333.332 0.675

Doing a final test

    las2las64 -i tmp_ft.laz -o tmp_ft.txt -oparse xyzXYZ

we see, the data itself (integer point values "XYZ", last 3 columns) are untouched, it was just header magic

304000                  33777.777439999998023 3.04           0  1111111 1000
304003.043040000018664  67555.554880000010598 3.37744     1001 12222222 1111
304060.806080000009388 101333.332320000001346 3.71488    20002 23333333 1222
304912.00912000000244  135111.109760000021197 3.04      300003 34444444 1000

as comparison we have our original file.
    las2las64 -i tmp.laz -o tmp_m.txt -oparse xyzXYZ

1000000                 103377.777440000005299 3.04          0  1111111 1000
1000003.043040000018664 137155.554880000010598 3.37744    1001 12222222 1111
1000060.806080000009388 170933.332319999986794 3.71488   20002 23333333 1222
1000912.009119999944232 204711.109760000021197 3.04     300003 34444444 1000


This method is fast and efficient, only disadvantage we can see is that you have to calculate your offset individual for each file (if you expect individual offsets).
If you have to do this we can assist you to find a solution for this probably advanced workflow.

Best,

Jochen @rapidlasso

[James Carracher]

Hi Kirk, yes I currently have -auto_reoffset as part of the same las2las instance. Integer overflows still occur

You received this message because you are subscribed to a topic in the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lastools/PiqPOAPYkqM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/ab9535cc-bcbd-4e80-833d-339829071ce8n%40googlegroups.com.

[James Carracher]

Hi Jochen,

I haven’t been able to get this to work. At least if I do what is in your las2las example about the files match exactly. The las info of the same files are what I would kind of expect if it did work though. And also get my head around it at the moment

How are you calculating what scale to use? It looks to me is the header scale x the conversion factor? So 0.01x0.3048 in your example
How do you calculate the offset too? Is that the same? Ie 1000000x0.3048

I could make up something using lasinfo and FME to work out adaptively what it should be if that’s the case

 

So as an example, here is the lasinfo of a file I’ve been supplied. Messy I know

In this case should I have a script like?:
lasinfo.exe -cpu64 -i test.laz ^

              -set_scale 0.0003048 0.0003048 0.0003048 ^

              -set_offset 706152 269764 0 ^

-repair_bb

James

[Jochen Rapidlasso]

Hi James,

yes, it should work if you multiply the existing scale and offset values by your requested factor.

In your sample the scale is like you suppose, but the offset would be

2316478.68163 * 0.304 = 704.209,51922

879493.87868 * 0.304 = 267.366,13912

2163.50752 * 0.304 = 657,70629

To simplify this: We will improve lasinfo64  to use an new argument like

lasinfo64 -i foo.laz -set_header_scale 0.304 0.304 0.304

to adjust the effective scale in all header values.

Please expect this change within the next days.

Cheers,

Jochen @rapidlasso

[James Carracher]

Hi Jochen,

Why is the scale you propose 0.304 rather than 0.3048 (the conversion factor between feet and metres)?

Does this new option you're suggesting adjust the scale and the offset? or just the scale?

James

You received this message because you are subscribed to a topic in the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lastools/PiqPOAPYkqM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/d558d45c-e04b-4c61-8947-59a0c891a707n%40googlegroups.com.

[Jochen Rapidlasso]

Hi James,

for me the 0.304 is just a number. In this case the first number in your first post of this topic :)

Of course you can (and should) use 0.3048 if you want to convert meters to feet.

If you just want to change scale, offset or bounding box in your header we have this arguments already.

What we want to do is a complete rescaling of the file without touching the points. So we give to option to change scale, offset and bounding box with ONE scale factor. The scale header entry can be just set, the offset and bounding box has to be calculated on base of the previous header entries.

Cheers,

Jochen @rapidlasso

[Jochen Rapidlasso]

Hi James,

please check out this beta:

https://downloads.rapidlasso.de/beta/lasinfo64.zip

You have a new argument "-scale_header":

"scale whole file by scaling the header values with factor [x] [y] [z] or [xyz] (one for all) (64bit only)"

So if you run 

    lasinfo64 -i foo.laz -scale_header 2

all values in the file are doubled.

    lasinfo64 -i foo.laz -scale_header 0.3048

will change each value from "meter" to "feet" without any overflow.

The point values won't be touched, only all header entries will be converted by this factor.

CAUTION: Don't run the command more than one time to a file: Each time you run, the header values will be multiplied with this factor.

It is recommended to make a backup of the original file before.

As long as nothing else is announced, this change will be included in the next release.

Cheers,

Jochen @rapidlasso

[James Carracher]

Thanks Jochen,

Seems to work great. Thanks. 

On another note, I saw the other day that the change you made in this post is not part of the full release yet? At least I didnt notice it in the las2las help
https://groups.google.com/g/lastools/c/RZ109cDC9jY/m/opgVOzNfCAAJ

James

[Jochen Rapidlasso]

Hi James,

thanks for the  feedback and for the reminder about the translate_scale_translate argument.

It is merged now to the next release.

Best regards,

Jochen @rapidlasso