[libpc] Dimension/Schema discussion

[Howard Butler]

Michael,

An immediate thing I noticed while implementing a non-LAS-conforming driver Friday is the desire to name my dimensions appropriately.  The names of course are set in a static array right now, and there isn't any way to override them.

My question is can you describe how what we have now is different than what I had been cooking in libLAS?  How was this design arrived at?

In libLAS, I had a boost::multi_index that included a random lookup and a name-based lookup.  Because of libLAS' point-at-a-time nature, this meant doing map look ups in the critical path and killed performance.  But this wouldn't be necessary with our PointBuffer-based approach, and dimension positions within a schema could continue to be fetched from outside the loop and passed into methods that would expect a position and a width to fetch.

We maintain an array of names, and a dimension type that is used to do random lookups in the dimensions array of Schema. . The slots are named to avoid doing so in the critical path, and we do our dimension name -> dimension slot lookup outside loops where we're fetching data.  Could we not continue to do that with the SchemaLayout maintaining the multi_index?

My complaint is that as we add more and more data providers, the Dimension Type system we've currently outlined is going to start feeling like quite a straight jacket.   The QFIT driver really needs two "X" dimensions because there's an X dimension of the sensor and X dimension of the measurement, per-point.  So these are logically X,  if we're to follow the dimension type system, but they can't be modeled that way because we can't have two X's.  

What could happen if we threw out the dimension type system we have now?  What would be the consequences?  What if the user "marked" their XYZ dimensions (first three are to be assumed that if no dimensions are marked) for use with bounds/windows/etc?  

Sorry for the still-a-bit-incompletely-formed-thoughts,

Howard