Request to change default resolution of writers.las

[lwiniwar]

By default, writers.las exports point clouds with a resolution of 0.01. In the case of geographic point clouds in metric units, this is 1 cm, which is quite rough for modern sensors. I therefore would suggest to change this default value to a more sensible choice, as first-time users may stumble upon this reduction in point cloud quality. I suggest 0.00025, representing 1/4 mm, as a better value, as this is also the default for industry-standard laser scanners such as the RIEGL V-Line, and set as a standard in their software RiScan Pro.

This should be as easy as changing these three lines: https://github.com/PDAL/PDAL/blob/72393aea220bd93c411e9fafbc447671aa43504e/io/LasWriter.cpp#L128-L130

I'm happy to submit a PR if this request is supported.

[hobu]

I'm happy to submit a PR if this request is supported.

This default has been 0.01 since LAStools in 2006, through libLAS, and now on through PDAL. The rationale for this default is the following:

• PDAL is most frequently used in aerial lidar scenarios, and no aerial scanners have 1/4 mm precision quite yet 😄
• Over-driven default scales means significantly less efficient LAZ compression for no value. Search for Isenburg's many posts on this particular topic.
• If we had a smaller default, people would more often overflow the 32 bit integer space when we go to store data, especially for data that spans large XY areas.
• When users reproject data into geographic space, a default of 0.01 means that we discretize all of their data to pile it on a single point – this has a nice benefit of illustrating the issue in a way that doesn't silently discretize their data to some "good enough" value that causes aliasing or other terrible effects.

It's the relationship of the last two bullets that has the most impact on the project. Answering questions helping people overcome 32 bit overflow situations are much more difficult than telling people to bump their scale_x and scale_y up if they're storing geographic units in their data. At this time we would much rather have more of the latter.

I understand this situation is annoying for users like yourself that have to be explicit all the time about scales whereas typical aerial lidar users of UTM data don't have to. That's however the audience we serve the most at this time...

[hobu]

That said, I could be convinced to change the scale_z default to 0.00025. @abellgithub ?

[abellgithub]

I don't like changing defaults because it will change behavior that people aren't expecting. They may have embedded PDAL in their software or use it on a routine basis for processing. I think this is especially likely in this case, as writing LAS is one of the most common PDAL uses. I would have no problem with a single option that sets the scales to some value if that's more convenient for a group of people. scale=.00025, for example, or even scale=tiny, but we should discuss the details more fully if we want to do something like this.

[abellgithub]

I don't know if option files would be helpful for your use, but I mention it just in case.

[lwiniwar]

Thanks @hobu for the elaboration. I understand the rationale and also @abellgithub 's reasoning not to change default values. However, as you pointed out, I run into the exact issue that the point clouds look good upon inspection, but points close to the (TLS) scanning positions pile up and I loose overall precision without noticing it directly (what your point with ALS and projection to geographic CS was).

I am unsure about warnings in PDAL, but could you imagine displaying a warning when points are collapsed due to this scaling? E.g. something like Applying the scale factor lead to ... points collapsing/overlapping. Choose a different output format or lower the scale values?

Thanks also for the suggestion cf. option files, will def look into that! Finally, I am personally not a fan of having a different default for scale_z, but that might just be me.

[abellgithub]

I don't know what you're doing with PDAL, but I assume that you're familiar with the forward option for writers.las. Many people are translating LAS/LAZ files and use writers.las.forward=all or writers.las.forward=scale. I think this is how most people maintain scale without thinking about it.

[lwiniwar]

I was not. That sounds like a good solution. Thanks! 😄