On 04/11/10 16:07, Howard Butler wrote:
Should we be hard asses and always throw an error?
Providing two modes for processing LAS files: strict and transitional.
Do our best to recover on a case-by-case basis?
Sounds like GDAL's approach to WKT and such.
The most common case of bad data that I've seen is invalid point
counts in the header. An accurate point count isn't so important for
LAS 1.0-1.2 data because you can provide a calculated point count by
measuring the size of the file, removing the header, and dividing
that value by the number of bytes each point takes.
If number of points in header is invalid
Read until one of the following is true
End of file
Number of consumed points equals number reported by header
In this most common case, I propose the following:
For LAS 1.0-1.2 we will use a calculated point count if the header's
value does not match the expected point count *and* the actual point
data contains the exact number of bytes required to completely
contain points (ie, point_data % point_format == 0).
This kind of implicit fixing of broken data stays in contradiction to
performance requirements.
Could be applied in transitional. In strict mode, just give up.
For LAS 1.3 data, we're going to just blindly believe the header, and
do no checking. If the modulo function fails, an exception is going
to be thrown with some numbers that someone could do some simple math
to maybe have a chance at figuring out what's going on.
Sound good?
I don't know. Broken standards always suck as standards.
However, see XHTML, it's not die hard always, but allows users to
consciously choose between string and transitional mode, and validate
their data against selected mode.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
