Copy classification with lascopy

[Zala Ferlic]

Hi, 

I'm having an issue using lascopy to copy classification between two types of LAS data. It works correctly for some blocks, but in others, it copies the classification incorrectly.

For example, in one case it copied some ground points as high vegetation. I've attached an example showing this problem.

Do you know what might be causing this? Any idea how to fix it?

Best regards, 

Zala Ferlic

[LAStools - efficient tools for LiDAR processing]

Hi Zala,

to help you we need much more information. 

What fields did you use to match your data?

What command did you run with which arguments?

What was the console output if you run the command with the "-v" (verbose) argument?

Then please support 2 small peaces of data (files to merge) so we can reproduce the problem here.

Cheers,

Jochen @rapidlasso

[Zala Ferlic]

Hi, 

Thank you for the quick reply.  

I ran lascopy using a batch file with the following setup: 

set PATH=%PATH%;C:\lastools_2025\bin

lascopy -i source.laz -i target.laz -o result.laz

The GPS time and return number were the same in both datasets - only the classification was different.

I didn’t use the -v (verbose) argument when running the command.

I'm sharing a WeTransfer link https://we.tl/t-cnvWZlKA68  with one of the blocks where the classification was copied incorrectly. Please use the data only for testing purposes and do not use it for anything else.

I’ve also attached a hillshade where you can clearly see the boundary between blocks - some of them have the classification copied correctly, while others don’t.

Let me know if you need any more information.

Best regards, Zala.

[LAStools - efficient tools for LiDAR processing]

Hi Zala,

thanks for the sample data.

You have used the 32 bit version of lascopy.

We did a complete redesign of lascopy recently. This is done in the 64 bit version of lascopy.

Using the new 64 bit version shows a different result.

You should use 

    lascopy64 -i source.laz -i target.laz -o result.laz

as command.

This will copy the point attribute "classification" by matching GPS time and return number.

The output is like:

LAStools lascopy (by in...@rapidlasso.de) version 250426 (demo only)
no attribute selected for copy. using default attribute 'classification' ...
no search key set by user: setting -match_gps_time and -match_return_number
match points using the following flags: -match_gps_time -match_return_number
reading attributes of 22686573 points from source file 'source.laz' ...
preparing attributes of 22686573 points from source file source.laz ...
WARNING: duplicate key count (each entry corresponds to a key): [2 2 2 2 2 2 2 2 2 2 2 2...]
copying attributes to 22686573 points of target file target.laz ...
done copying attributes
done with 'result_64.laz'. copied 22686573 point attributes. total time 44.821 sec.

The warning tells you, that there are several points with identical [GPS time and return number] key.

This means that some points are maybe not copied the way you expect.

It would be good to change or extend your matching key to get a unique value for every point you have.

Please check this and retry, if you can not solve it we will try to analyze deeper.

Thanks,

Jochen @rapidlasso

[Zala Ferlic]

Hi, 

Thank you for reviewing the data.

I have tried running the process using the new command lascopy64 on 12 blocks. However, the shape of location with the incorrect classification remains the same. I’m also wondering why the classification is transferred correctly on some blocks and partially on others. 

Attached are two images of hillshades, one created using lascopy and the other with lascopy6 where it's clearly visible that the errors occur in the same locations. I’ve also noticed that the shapefiles with the errors do not correspond to any specific single line.

Could this issue be related to the fact that our laser scanning system consists of two separate lasers whose data are merged into a single LAS file? Points do not have information about scanner numbers. 

In your recommendation, you mentioned using unique values. Does this mean that we need to assign a unique value to each point in advance? If so, how would we best approach this in practice?

Thank you for your help and kind regards,

Best regards, Zala.

V V pon., 28. apr. 2025 ob 14:54 je oseba LAStools - efficient tools for LiDAR processing <last...@googlegroups.com> napisala:

--
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 visit https://groups.google.com/d/msgid/lastools/1ae3d3ae-3a0f-4cb8-8db6-106e8f43d74bn%40googlegroups.com.

[Michael Perdue]

Hello,

If your system has dual channel data, then you need to find another field that will uniquely identify points. With dual channel instruments, it's a virtual guarantee that points from seperate channels will have identical time tags/return numbers. Ideally you have populated the channel number into the two files before they were merged, but we have had problems with terrscan corrupting this field, so we give every flightline/channel its own unique point source ID and use that as a match field.

If you didn't do anything to keep the channels separable when you combined the data, it gets more complicated. If the coordinates have not been shifted/calibrated, you can try -match_xyz 0 as the channels should never be coincident in 4D space. But if you did any significant shifting of the data that may have problems as well. You could also try using intensity as a match field but I have found I still get collisions when I've needed to rely on that field.

Cheers,

Mike

To view this discussion visit https://groups.google.com/d/msgid/lastools/CAAjkso%3DG9J55E39f2ZqN8gmQ8OR%3DvYo0gEBvPLTDOWLKNGZSjA%40mail.gmail.com.