On 04/11/10 18:25, Mike Grant wrote: > On 04/11/10 16:07, Howard Butler wrote: >> This email asks what should be our default stance should be in the >> face of bad data. Some things, like an invalid point count, are >> partially recoverable, but attempts to reconcile many other will >> often result in proliferating bad data. Should we be hard asses >> and always throw an error? Do our best to recover on a >> case-by-case basis? > > I'd just throw an exception when a LAS file isn't standards > compliant (+1 hard ass).
+1 > A separate tool can be written that catches these and tries to fix > up files. This keeps things clean and gives direct feedback on > naughty LAS files. > > If you want to include additional code to handle bad data, it would > be definitely be nice to be have a flag that enables or disables > this behaviour (the strict/loose interpretation Mateusz suggests). I think I misunderstood a bit the initial concept of separate tool. I assume this tool would use the libLAS library with all the validation and clean-up logic built-in. Certainly, it would pollute the library implementation quite a lot. So, I second the idea of separate tool with as much cleaning logic in it as possible. As Howard mentioned, it would be based on custom implementation of ReaderI interface. 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
