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
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
