[Liblas-devel] Header::SetDataFormatId, and supported schemas

[Howard Butler]

On Mar 7, 2011, at 10:02 AM, Howard Butler wrote:

> 
> On Mar 6, 2011, at 8:53 AM, Martin Isenburg wrote:
> 
>> hi ben.
>> 
>>> ePointFormat0: has dimensions "X, Y, Z, Intensity, Return Number,
>>> Number of Returns, Scan Direction, Flightline Edge, Classification,
>>> Scan Angle Rank, User Data, Point Source ID".
>>> 
>>> ePointFormat1: all of those, plus it adds "Time".
>>> 
>>> ePointFormat2: adds Color ("Red", "Green", "Blue")
>>> 
>>> ePointFormat3: adds "Time" and Color.
>>> 
>>> ePointFormat4: adds "Time" (and WavePacket?)
>>> 
>>> ePointFormat5: adds ???
>> 
>> ePointFormat5: adds "Time" and Color and WavePacket
>> 
>>> Besides clarifying those options a bit more for the documentation,
>>> could someone tell if this means we cannot define our own schema?
>> 
>> We cannot. LAS has those 6 point types. If you only use XYZ and RGB
>> then you should use point type 2. If you are worried about space (e.g.
>> storing too many unused fields) you can consider leaving all those
>> fields at zero and storing your data LASzip compressed ... they will
>> be pretty much "compressed away" completely.
> 
> I would say this is not entirely descriptive.  It is legal LAS to have all of the fields of the "fixed" portion of the point format *plus* any extra bytes beyond the base point format that can contain whatever you want.  libLAS liblas::Schema attempts to model this by allowing you to initialize it via a point format (ePointFormat1, ePointFormat3, etc) and then go add any liblas::Dimension items you wish to describe anything else you want (they must be aligned to a single byte, but sub-byte-sized dimensions are allowed if they pack to byte boundaries -- this is how a number of dimensions in the base point formats are modeled).  After that, you set the header's data format id to your point format, and then the data record length to the complete size 
> 
> This work is not yet complete in libLAS 1.6.0, however.  The code that describes custom schemas (those that have dimensions beyond the base point format-required ones) is done, as is some XML description of these schemas that can be put into a VLR to support interpretation of the extended data, but the code that actually reads and writes the extend data in liblas::Reader and liblas::Writer is not done.  This 

oops.

This work still has to be done, but my momentum is pushing it toward being completed in libPC, where it fits much better than in libLAS, where it ultimately ends up being really confusing.  

Another mark against doing this in LAS is that while legal, I think many LAS readers/writers assume fixed point formats only (and assume a point record's byte size from that), and emitted these extended LAS files might proliferate interoperability misery.  libLAS' mission is to decrease interoperability pain, not make it worse :)

Howard