[Liblas-devel] Dealing with "bad" data

[Volker Wichmann]

Am 04.11.2010 17:43, schrieb Andrew Bell:
> On Thu, Nov 4, 2010 at 11:07 AM, Howard Butler<hobu.inc at gmail.com>  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.
>

I'm in favour of this approach too - provide a utility which tries to 
fix broken files but always throw an exception in case a file is not 
compliant to the specification. This will allow users to have some 
control on how to handle such files.

Volker