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

Subject: Re: [geometry] Geometries represented in multiple point types
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-02-07 17:42:11

Hi Andrew,

On 31-1-2013 21:58, Andrew Hundt wrote:
>
>             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

Thanks for your compliments. The system (and the blog-page) were at that 
time written for a specific usage (handling multi-s together, etc) but 
indeed they have a more generic ability.

Also on those more general places it is indeed possible to use them, we 
discussed this internally and will apply this in the library. However, 
it can take a while before it is modified everywhere.

Regards, Barend