[Liblas-devel] LAS 1.3

[Howard Butler]

On Apr 28, 2009, at 3:19 PM, Mateusz Loskot wrote:

> Howard Butler wrote:
>> is gonna kick our ass.
>> https://lidarbb.cr.usgs.gov/index.php?showtopic=6385
>>
>> Specifically, a number of header and VLR sizes are now going to be
>> uint64_t's rather that uint32_t's.  grr....
>>
>> The committee doesn't pay attention to libLAS (I think they should as
>> an open reference implementation, but that's another story), so if we
>> have any comments about the spec, we should collate them together,
>> and I will send them on.  I have been working to get myself added to
>> the committee so that I can participate in future specs, but it looks
>> like we're going to have to eat this one whole :(
>
> I have read it. My eyes opened wide. Looks like the extend of messing
> specification process of ASPRS LAS has reached zenith.

I think it would have been prudent to fork off the waveform stuff into  
its own entire spec rather than mixing it up into the existing spec.   
We don't generally mix rasters and vectors within the same file format  
-- why mix the analogous points and waveforms?  LAS 2.0 was a failed  
attempt at that, and now 1.3 is a drastic enough change that it breaks  
compatibility with the 1.x specifications.  I don't think it should be  
called LAS ... maybe LSW 1.0 or something.  It's not bad to have  
multiple specs.  It is bad to mix multiple specs in such a way that  
people think they are the same because then it gets dumped in the laps  
of the implementors -- us.

> Given that, there is ~~some~~ a lot of work that has to be done.
>
> First idea that came to my mind is to encapsulate (implementation)
> details of reading point data formats in form of micro-readers, lets
> say, point record readers. Then, file readers could act as clients of
> point readers.
>

This is a great idea regardless off whether or not we go on to  
implement 1.3.  It's quite miserable that we now have 4 point formats  
x 4 versions though, with a worst case scenario of having 16 different  
point format readers/writers, but in reality it is less than that.   
Each successive LAS specification has the potential to geometrically  
increase the number of permutations we might possibly have to track --  
while the actual number of permutations would be less.

What do you mean file readers act as clients of point readers?

I will note that I am now part of the committee, but I did not  
participate in the 1.3 specification development.  It is very  
disappointing that the committee continues to hammer the specification  
so drastically from release to release.  I understand the push-pull of  
specification development, but in my opinion continuity across  
versions is one of the most critical for implementation and adoption.   
It is better to call something a different name than to call it the  
same name but have it different.  1.3 implies lineage with the 1.x LAS  
specs, but it is really quite different, and no 1.2 reader is going to  
be able to read 1.3 data in any way, shape, or form.  Competing  
interests say, "but we *need* larger numbers to hold such and such,"  
which is a challenge, but I say err on the side of complicating the  
spec to perpetuate continuity than throw out lineage that would be  
straightforward to preserve.

Howard