[Liblas-devel] Point implementation proposal

[Howard Butler]

All,

Consider the following assumptions:

1) The committee keeps adding fixed schema fields every single release (only 7 new fields added for 1.3! !@#$!! :)
2) Old schemas (point format 0, 1, 2, 3) remain relatively stable from version to version of the LAS specification
3) Adding support for new point formats means large-scale updating of the liblas::Point class
4) The current implementation of liblas::Point only uses header information for scaling and offset, but no other essential interpretation of the point data is done at the time it is read from the file.
5) It is currently impossible to fetch uninterpreted (mostly wanted in the case of unscaled X, Y, Z) data from the liblas::Point.
6) Extended schemas <https://lidarbb.cr.usgs.gov/index.php?showtopic=9075>, while legal, aren't practically implemented anywhere.

I would like to propose that we (well, I rather) re-engineer the internal workings of the liblas::Point class to do the following:

* carry around its raw data in the form of a boost::array
* interpret its raw data *on-the-fly* for each fixed attribute call (GetIntensity, GetX, GetClassification, etc) we currently support.
* provide a method for fetching the complete uninterpreted data array on liblas::Point
* optionally carry a pointer to a liblas::Header for scaling and schema information.  Points read off of a file, for example, will have a back reference to their header
* provide (some day) a generic schema-aware interface for fetching interpreted data from the point.  The first pass implementation is going to leave it to the developer to read the schema and interpret the data

A related item of this work would be beefing up the liblas::PointFormat class (this hadn't been released yet, but existed in the unreleased repository code), renaming it to liblas::Schema, and adding reader/writer support to store these things in libLAS-only VLRs.

Downsides?  I'd be interested to hear any feedback.

Howard