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