Missing DEM pixel with las2dem (-cpu64 and -use_tile_bb)

[Florian Gandor]

Hi,

I have encountered (probably) bugs with las2dem, namely missing pixel (nodata) in the dem generation for a buffered lazfile. 

1. First bug is when using the -cpu64 version of las2dem, some pixel are sparsely missing (red is nodata):

.\las2dem.exe -i "D:\temp\2762750_1260250.laz" -otif -elevation -step 0.5 -nodata -9999 -use_tile_bb -cpu64 -kill 300 -spike_free 2.0
there were 1039 clipped rasters (and 249998 unclipped ones)

 

When using the 32 bits version of the program, the result is correct:

.\las2dem.exe -i "D:\temp\2762750_1260250.laz" -otif -elevation -step 0.5 -nodata -9999 -use_tile_bb -kill 300 -spike_free 2.0

there were 1039 clipped rasters (and 0 unclipped ones)

2. The second bug founded also concerned missing pixel on the edge of a DEM when using -use_tile_bb. The input lazfile is a buffered tile with enough points on each side of the tile.

.\las2dem.exe -i D:\\temp\\2762750_1260500.laz -spike_free 2.0 -otif -elevation -step 0.5 -nodata -9999 -use_tile_bb -kill 300 -ll 2762735 1260485
there were 1016 clipped rasters (and 0 unclipped ones)

When dropping the -use_tile_bb parameter, the whole lazfile (with buffered area) is complete as it should be.

.\las2dem.exe -i D:\\temp\\2762750_1260500.laz -spike_free 2.0 -otif -elevation -step 0.5 -nodata -9999 -kill 300 -ll 2762735 1260485

This behavior makes me believe that there are two annoying bugs, one with the cpu64 command and the other with the use_tile_bb command. 

The workaround, I was forced to use is to use the 32 bits version of las2dem and to clip the raster in another software... 

I can send the necessary files to reproduce the problem if required. My lastools version (with license) is 190812.

Do other users have similar issues ?

In advance thanks for (maybe) fixing these bugs. 

Florian

[Eric Putman]

Hi Florian,

I have experienced similar issues with void pixels in LAS2DEM and I believe this is an actual and repeatable bug. I did some quick checks at the time and it seems that these void pixels occurred in TIF, BIL, and ASCII format exports (and presumably all other formats as well).

I meant to submit a similar issue report a few months ago, but it slipped my mind. 

Hopefully Martin will see and address this. If needed, I could probably put together a reproducible example as well.

R,

Eric

[gberard]

I had an issue a while back that seems very similar but cropped up under different circumstances (blast2dem with merged inputs, manually specified output lower-left coordinates + number of rows/cols).  Linking it here in case it's related and helpful to Martin:

https://groups.google.com/g/lastools/c/s6ISeQ7l87A/m/8QLVhaulCwAJ

We corresponded outside of the thread where I sent him a test case, and he was able to reproduce the bug but not diagnose it.

Greg

[Eric Putman]

Hey Martin,

Have you had a chance to look into this?

The 64 bit functionality is really valuable to me, but this apparent bug is unfortunately a major deterrent for using las2dem on work where I would otherwise prefer to. For some applications, a few void pixels probably doesn't matter much, but on other applications this could cause analytical issues or a rejection of deliverables. Cleaning up these sporadic void pixels throughout thousands of tiles in GIS software is a challenging post-processing operation, so avoiding that issue would be a much appreciated resolution.

Thanks in advance and long may LAZ reign!

R,

Eric

[hyd...@gmail.com]

Hey Eric,

Have you tried with the latest version of LAStools? You seem to be using quite an old version (190812), and the latest is 200619.

[Eric Putman]

I think I'm due for an update and probably should have done so as my first step.

I'll update and try to see if I can recreate those void pixel occurrences on the latest version. Thanks for the reminder.

R,

Eric

[Guilherme Sanchez]

Eric,

Have you tested the new version?

I have had this problem a few times and work around the situation using the Global Mapper fill_gaps feature.

But now a customer asked me to keep the water bodies as NO_DATA and I have to disable this function and I would need lastools to generate the surface without this problema.

Regards

--
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
---
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/0ff3c990-82b8-4729-a771-bf87003277fao%40googlegroups.com.

[Mark Levitski]

Single elevation water bodies require an iso-polyline at edge of water elevation. So if you can use some software to find that (for instance as a single elevation contour), then it can be used as an exclusion area shapefile. 

Flowing water bodies are a different animal.

To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/CAGxwCidbJobdxSUhSVbu4V9Qkq2U6RWkBdAjR-Zxy%3DQxm53VrQ%40mail.gmail.com.

[guilherme sanchez]

Thanks Mark for the help.
However, the generation of DEM with bodies of water is not in question here.
Perhaps I expressed it badly, as it was just an example.
What I meant was:
- this missing dem pixel problem happened to me sporadically;
- I solved the situation using another software function;
- I need to disable this function, so I am interested in solving this las2dem problem.

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/CALG8ac8DgkivYozeszsUaCpNNNFNu_3DUV3tASMr-PqXC5oBsg%40mail.gmail.com.

[Eric Putman]

Hello Everyone,

To bring this topic back up, I had updated my LAStools to version 201003 (running a commercial license) and I am still seeing apparently random null pixels throughout DEMs generated with las2dem when running in 64 bit.

I can try to put together a repeatable example for the rapidlasso team if that would be helpful, but I wanted to report that this seems to still be a bug.

These void pixels are clearly not related to any data voids, etc. They always appear in the form of a single pixel (as opposed to a cluster or group of void pixels) and don't seem to suggest any sort of spatial pattern.

[brent.m...@gmail.com]

Hi,

Just confirming that the error described by Eric Putnam is still present in the latest version. I'm also running a commercial license and the only workaround seems to be to run the 32bit version.

As stated by Eric Putnam, these void pixels are clearly not related to any data voids, etc. They always appear in the form of a single pixel (as opposed to a cluster or group of void pixels) and don't seem to suggest any sort of spatial pattern.

An update would be greatly appreciated. Thanks!

[Jochen Rapidlasso]

Hi Brent,

this problem is known and high priorized. We will try to fix this soon.

Best regards,

Jochen @rapidlasso

[brent.m...@gmail.com]

That's great news! Please let me know when it it's fixed.

[Eric Putman]

Hi Jochen,

I'm glad to hear this is acknowledged and a fix is underway. Looking forward to the resolution of this bug and to being able to utilize las2dem in more production-focused workflows.

Thanks in advance and long may LAZ reign!

R,

Eric Putman