[pdal] Array Dimensions

[Chris Foster]

On 2 July 2013 01:18, Howard Butler <hobu.inc at gmail.com> wrote:
>> It seems to me that requiring
>> spatial context in a filter goes a bit beyond what pdal was designed for, but
>> given you do everything in chunks I'm hoping it's possible without too much
>> effort.
>
> I've been thinking about this one too. PointBuffer does carry its "bounds" around, which I've used
> for some communication (mostly going in/out of database backends), but we haven't hinted the entire pipeline
> with spatial awareness.
>
> Additionally, there's a FLANN-based filter available, and that's not plugged into everything like it should.
> I don't know that I want to make FLANN a hard dependency, but I've found nanoflann, which is an
> all-in-one-header port of BSD-licensed FLANN, so that could be a possibility now. I'd be interested
> in any ideas you have to make this aspect better.

Agreed that making FLANN a hard dependency would be a bad thing.  I don't have
any specific thoughts about how this would hang together yet, all I know is
that the filter will need all available points within a spatial region
(including a buffer for extra context) before any filtering decisions can be
made.  I suspect that baking in a particular spatial data structure would be a
mistake to start with - in principle each filter stage needs different kinds
of spatial queries, some of which may require building a specialized
acceleration structure.

>> Right.  Question: what's the distinction between UnsignedByte and
>> UnsignedInteger?  It's confusing to me to have both of these.
>
> *interpretation* is the keyword here, not merely type. Do I interpret this
> dimension as byte or integer? The idea was that I might care about the
> difference. UnsignedByte isn't used much though, and it could be removed
> without consequence if it is clear this just makes things confusing.

Ok, so UnsignedByte is more like "raw bucket of bits"?  I can definitely see
the case for a raw interpretation of some kind, allowing arbitrary serialized
user data to be passed along without pdal messing with it.

>> Arrayness seems orthogonal from the element type to me.  In the past I've
>> flagged arrays simply by having element count > 1.
>
> The getInterpretation is to be able to discriminate how we should treat a dimension.
>
> again, interpretation, not type. So for boost::array<float, 9>, we'd have
>
> getInterpretation() == dimension::Float
> getElementCount() == 9
> getByteSize() == 4*getElementCount()

Sounds sensible, I was imagining you meant pdal::dimension::ArrayType was a
possible return value from getInterpretation().  I'm still not sure how
ArrayType fits in here.

>> Another more wacky thought which crosses my mind is that it would be
>> helpful to have aliases (eg, "Red", "Blue" and "Green" dimensions alias
>> fields of the "Color" dimension which is a three element array per point).
>> This would be rather handy for me since I actually don't care to read the
>> color components separately, but it might be too hard to get right.
>
> /me strokes his chin and wonders how messy dimension aliasing could get.
>
> I'm not against it, mind you, but I'm just a bit worried that the
> dimension/schema stuff is a bit messy as it is.  Pull up a chair and let me
> tell you about dimension inheritance when you have the time... :)

Yep, the hoops which you jump through to do this are obvious in the code.
Don't ask me what they do just yet, but I can see them there :)  Certainly I
won't bother tackling aliasing until I have a much better understanding of the
chaos it would cause.

~Chris