Geometry Boost List: Re: [geometry] Geometries represented in multiple point types

Subject: Re: [geometry] Geometries represented in multiple point types
From: Andrew Hundt (athundt_at_[hidden])
Date: 2013-01-31 15:58:30

>     bool gpfalse = boost::geometry::within(gpo,db);
>>
>
> Since within() can take 2 different geometries with potentially different
> point types, I'm not sure to understand what can't be done in the code
> above using a mere grid point box. I.e. a grid point box can be passed as
> first argument of within() while passing a world point as 2nd argument. But
> maybe this particular code doesn't tell the full story of what you're
> trying to achieve?
>

The two types actually can't interact because the "Unique" template
parameter in struct point makes each instantiation of different types, in
the same way that the Boost.Units dimensional analysis library provides
compile time protection against assignment of values that measure different
units.

The code in my message does not compile because within() and related
functions don't use tag_cast.  I would like to be able to add additional
functionality to differentiate different kinds of points In the same way as
point_tag:

// From boost/geometry/core/tags.hpp
/// OGC Point identifying tag
struct point_tag : single_tag, pointlike_tag {};

I believe it should still be possible to further specialize point_tag
without breaking things.

With respect to my specific case, perhaps I should instead be either
inheriting from cartesian_tag or using the boost.units quantity_point
extension.

The reason I originally expected point_tag to be extensible in this way is
due to Barend's excellent posts on tag dispatching:
http://barendgehrels.blogspot.com/2010/10/tag-dispatching-and-inheritance.html

Regarding the possible difference of scale between a grid point and a world
> point (your comment in the code), this is a different issue that probably
> appeals for something like a transformed view...
>

In the general case it could include any arbitrary transformation: scale,
offset, rotation and transpose. This would make sense when points are
essentially a proxy for addresses that can't be transformed as easily, such
as the actual pixels referred to by (x,y) coordinates in an image.