Re: [boost] Geometry and spatial indexes, my opinion

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Patrick Mihelich (patrick.mihelich_at_[hidden])
Date: 2008-10-08 19:23:47

On Wed, Oct 8, 2008 at 2:53 PM, Michael Fawcett
<michael.fawcett_at_[hidden]>wrote:

> On Wed, Oct 8, 2008 at 5:33 PM, Patrick Mihelich
> <patrick.mihelich_at_[hidden]> wrote:
> >
> > Cool, compile time indexing is very useful. But, I'm not sure I see the
> need
> > for using tuples. I can't offhand think of a use case where the
> dimensions
> > are of heterogeneous type, so wouldn't a simple array work?
>
> Sure a simple array should work.  The point of a generic library is
> that a simple array would work, so would a tuple, and so would your
> custom point class.
>
> As for the heterogeneous types, think of huge (GBs worth) digital
> elevation models in meter units where altitude is in a range from 0 -
> 20,000m.  In that case, my point type would be something like
> vector3<int, short, int> instead of a vector3<int>.
>
> With a 1024x1024 file, that would result in a savings of only 2MB of
> memory, but extrapolate that out to a 16384x16384 file, and the
> savings is 500MB.

OK, yes, I'm convinced. Support for heterogeneous types has its uses. But I
will still ask, why use a tuple to store the data in the basic (Cartesian)
point class? Barend and Bruno's library uses an array instead, which I think
should be preferred for two reasons. (1) I would still think the homogeneous
case to be much more common the heterogeneous case. (2) Using a tuple makes
it difficult or impossible to use the generic point class in high
dimensions. Consider

typedef geometry::point<float, 128> sift_descriptor;
vs.
typedef geometry::point< fusion::vector<float, float, float, float, ... /*
128 of these */> > sift_descriptor;

which is probably beyond what Fusion supports, and would break the compiler
anyway. For your use case, it would of course be possible to define your own
heterogeneous point class.

Now that I think about it, it could be very interesting to make the provided
point classes Fusion-compatible sequence types via the extension mechanism.
After all, we are already agreed on supporting compile-time access. And
then, why not go all the way and write the default implementations of the
core algorithms on top of Fusion? In that case

typedef fusion::vector3<int, short, int> dem_point;

would work out of the box.

Patrick