[Liblas-devel] LAS Schema

[Howard Butler]

On Mar 17, 2010, at 3:34 PM, Mike Grant wrote:

> On 17/03/10 15:43, Howard Butler wrote:
>> If we think this is legal, it would be a simple extension to allow the
>> LASSchema to be written into a VLR that describes the layout of this
>> extra data *within* the LAS file (as well as coincidently help me
>> describe data in OPC, but that's an unrelated issue).
> 
> This sounds like a very neat extension to the LAS format that doesn't
> break the existing specification.  

We'll see what/if the LAS priests say.  There might be a difference in how I read things and what they meant to say :)

> In terms of liblas / reading standard
> LAS files though, what would the purpose of this be?

It wouldn't change standard files at all, even through libLAS, but I might make it the mechanism to allow you to easily store and manipulate additional dimensions of data (and just as importantly, cache summary information for more than the XYZ within the metadata -- which we can't do right now).  

My current goal is to get people thinking about LAS as something different than a fixed-width and rigid, poorly implemented database table.  It doesn't need to be HDF or NetCDF, but it would be nice to have something slightly more convenient and flexible, while still easy enough for implementors to write code to consume.  

> 
> I can see it definitely helps with your OPC problem and suggests a
> (nice) possible future path for a new LAS [12].x, but I'm not sure if
> it'd currently add to the fragmentation of formats problem that others
> have mentioned.  If this were part of an official, well defined and
> well-considered new specification, it sounds like a nice generic
> solution to the variability of point data formats.  As an extra
> libLAS-only format it risks being another variation, and one that might
> be overridden by a LAS 1.4 / 2.0 spec at any time.

The proposed solution would not break the format at all, and as long as readers are not making hard assumptions about the relationship between pointformats and their sizes with respect to the data record length, will not prevent existing readers from being able to consume the data.

You are correct that in my case it is most immediately applicable to OPC, but I thought there might be more general interest.  


> 
> On that note, Martin's call for a 1.4 workshop also sounds interesting,
> but I'd politely suggest avoiding getting a new spec done quickly - that
> seems to have been the problem with 1.3.  Take the time to get feedback,
> get community support and get it right.  

There needs to be a public discussion mailing list instead of a hand-maintained CC'd list of people who can be forgotten that allows anyone who wants to to participate.  

> As someone not particularly
> versed in all the various LIDAR formats, it'd also be really interesting
> to see a consolidated list of issues that need addressing - and
> hopefully would help form an agenda for the workshop.
> 
> Pardon the notes of caution - as someone that's got LAS 1.3 files to
> handle, I'm feeling a little burnt ;)
> 
> Cheers,
> 
> Mike.
> 
> P.S. we're going to provide a LAS 1.3 file for the sample archive soon,
> though I understand we may not be able to read it for a long time!

The points should be able to be read by libLAS, just not the waveforms stuff...