Redefine "Overlap" bit as "Overage" about las

[esilvia]

The consensus from the 5/18 as I understood it was that renaming this field would only add confusion to a feature that is little understood and used even less, especially since the scant software that does support Overlap already calls it that. Therefore, the best solution seems to be to add an example and leave the name alone (see screenshot).

Does that help address the concerns from the last LWG meeting without causing any damage to existing implementations?

[HKHeidemann]

I concur with Evon. Both OverLAP and OverAGE are valid descriptors, but of different things.

OverLAP is a static positional condition of one swath (or lift, or project, or ...) relative to another swath (or other piece of data). Once data is geometrically finalized, the OverLAP is also finalized. Whether or not a point is "OverLAP" is immutable: It either is, or is not, in that area.

OverAGE is a spatial (x-y) subset of a swath, which as Evon VERY nicely put it, "[is] unnecessary to achieve a consistent “depth of coverage” (meaning single, double, whatever)." The condition of OverAGE IS mutable; any user may choose to redefine the exact boundaries of the "tenderloins", while remaining complete and non-overlapped between them, and thus, which points are OverAGE.

Evon's point - suggesting suitability of these points for any application is beside the point and should be avoided - is also spot-on.

[esilvia]

Funny that you like the wording, since most of that was copied directly from some of your posts. :)

I think my primary concern with altering the label/wording in the specification is that some may have implemented use of the Overlap flag based on the current definition and therefore this change would be construed as breaking binary compatibility. Does anyone know of any implementations that implement the Overlap bit as OVERLAP rather than USGS's desired meaning of OVERAGE?

[HKHeidemann]

I believe that "overage" was the original intent of both the earlier classification as well as the current flag -- that the "problem" lies merely with the term being used. I will be interested in hearing if anybody has been using it for actual overlap. I don't think I've ever seen one here at EROS.

[jdnimetz]

@esilvia I believe the descriptions you've listed in preceding post are good as-is.
Regarding overlap:
I agree that usage of overlap bit flag is not very well understood, as evident by the variability in its usage in multiple airborne lidar datasets available in the public domain.

Of particular concern is how to assess point cloud density and distribution when this flag is used. Should overlap-flagged points be counted for acquisition-designed (i.e. "nominal") first-return density? Should these points be ignored in this assessment? What about terrain (ground) density? Should these points be counted or ignored if they are not used to create bare earth DEMs derived from the point cloud?

Use of the overlap bit flag is sometimes confused or conflated with use of the withheld flag. I've seen airborne lidar datasets where the same point is flagged as both withheld and overlap because it meets the data producer's selection criteria. The differentiation can be muddy; if a point should be ignored for the purpose of deriving a model, doesn't this indicate a problem with the point's geometry? If so, isn't the withheld flag alone the right choice for differentiation?

Curious to hear others' thoughts on the use of overlap and withheld flags, either together or independently.

[esilvia]

@jdnimetz I think it's up to the user as to whether or not Overlap points are included in density computations. Generally, I'd say they should be included when assessing whether a dataset was acquired to meet a certain specification, but excluded when producing DEM rasters.

It's correct to say that Overlap and Withheld represent two different situations. Withheld points are either invalid returns or geometrically unreliable. Overlap points are potentially valid but "extra" in the sense that they are not required to meet the needs of the application and were identified as the least important points in that overlapping region. Points that fall within the "extra" region for that swath and are also geometrically unreliable may be both Overlap and Withheld, such as "stacked" points at the very edge of an oscillating mirror scanner.

[esilvia]

I believe this discussion is closed. Feel free to reopen if we need to revisit.