[pdal] Array Dimensions

[Howard Butler]

On Jul 1, 2013, at 10:24 PM, Chris Foster <chris.foster at roames.com.au> wrote:

> On 2 July 2013 01:18, Howard Butler <hobu.inc at gmail.com> wrote:
> 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.

Correct. Sometimes you want an octree, sometimes a kdtree, sometimes something else. Trying to allow you to plug into an index in any sort of generic way is difficult.

My first cut at this was to make a filter that simply passed-through the data as it were consumed by a pipeline, and then you cast(ed) the filter into a concrete type and used its special methods to find points, etc. It's not perfect, but it kind of works (see pcequal for some example)

> 
>>> 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.

Yes, exactly.