Export LAZ File

946

Hello,

I guess there is a bug when exporting LAZ file cropped to a selected polygon for the last builds of version 26.

The output LAZ file is cropped to the bounding box of the selected polygon and not to the polygon it self.

Regards,

R

bmg_mike

Which version and build date of GM 26.0 are you seeing this in?

I just tried in the very latest 26.0.3 daily build and a LAZ export cropped to a polygon only included points inside the polygon as expected.

Thanks,

Mike

Global Mapper Guru

946

Hi Mike,

It's the build from 010925

You can see in the image the original and cropped file with corridor polygon and also the build version.

The polygon (Geometry=529 vertices, Perimeter: 29.133 km, Area: 4.288 sq km, Bounds: (486784.396,525150.280,498686.108,528129.798) is valid so no self-intersections.

Tried to crop against other, smaller poly but with same result. Always the exported file is according to the BBox of the poly.

If I select all lidar points inside polygon, the selection is correct.

Thanks,

Robert

946

Tried also to open in TextPad the gmw file I used for this example and just realised it was bigger than 300mb but with no reason other than 5 000 000 lines with this type of text:

As the test workspace was created from my original workspace (by selecting some layers and creating new workspace from ) I am assuming that the original workspace is somehow corrupted too.

The main workflow was this:

Opened 8 LiDAR strips and fit each of those to GCP s using "Best Fit Plane".

Save the workspace

Load the corridor polygon and export 1 file only with points inside polygon.

Loading the resulted laz file and noticed that the export was not as expected.

Save the workspace / install last build / Open and repeat the cropping step with the same result.

Select the exported LiDAR file and the corridor polygon and created the workspace I did the print from.

At this point I opened an empty workspace, load the exported lidar file as it was, and cropped again against the corridor polygon with the expected result.

My conclusion is that some of the steps I did messed up the workspace and from that the unexpected behavior.

bmg_mike

The .gmw actually looks fine. That huge chunk of random looking text is actually UU-encoded binary data for the modifications you made to a layer after load time (from the best fit).

Could you make a case that reproduces the issue and send it to geohelp@bluemarblegeo.com or share on a Google Drive or something? Even if it's just your whole large workspace with crop polygons, that would be fine, but the smaller the test case the better.

Thanks,

Mike

Global Mapper Guru

946

I managed to reproduce the error with smaller lidar samples.

I sent a mail to geohelp with the workspace and also 2 lidar samples - (v26_b010925_laz crop test.zip).

In the image you can see with intensity the lidar file to crop and with elevation the resulted cropped file not respecting the selected polygon boundary.

All the best,

Robert

bmg_mike

Hi Robert,

I've let support know to send it on to me if/when they can reproduce the issue. Should be easy to fix once I can make it happen.

Thanks,

Mike

Global Mapper Guru

bmg_mike

Hi Robert,

We were able to reproduce and fix this based on your sample. It could happen when cropping Lidar on export when the Lidar layer projection was different than the display/export projection (the datum was different in your case).

The 26.0.x daily build should be updated in the next couple of days with the fix.

Thanks,

Mike

Global Mapper Guru