On Thu, Nov 4, 2010 at 11:07 AM, Howard Butler <[email protected]> wrote: > All, > > There are a number of softwares that are quite lax in how they write LAS > files. Some of the things I've found softwares doing include: > > * miswriting and generally screwing things up in the header, but having a > legitimate offset so you could read points > * writing invalid point counts in the header (very common) > * following the extremely broken LAS 1.3 R10 specification that had a 7*long > return count in the header instead of the required and expected 5*long > > 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?
If you are detecting the problem anyway, why not just throw the exception and if someone has the energy, write a utility that will try to coerce the bad data into good data. That way you don't have to clutter the code with non-conforming crap but would still have a way to get to something useful. This is pretty typical for DBs. -- Andrew Bell [email protected] _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
