Geometry Boost List: Re: [geometry] Run-Time specified geometries

Subject: Re: [geometry] Run-Time specified geometries
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-05-03 07:50:46

Hi Samuel,

Samuel Debionne wrote:

<snip>
>> I think you shouldn't be forced to think about all possible details that
>> may not compile. If the algorithm and strategy are implemented for
>> passed Geometries and Geometries are correct (Concept checks are for
>> this purpose), everything should compile. Otherwise it's probably a bug.
>>
>> Regarding the compatibility of Geometries, it could be done on the
>> dispatch::xxx level. Where are those explicitly dimensions compared?
> I have an example of such shortcut. I'm working on a runtime version of
> the distance algorithm, moderate complexity but already plenty of
> interesting problems ! In the projected_point strategy class code like
> this is found :
>
> boost\geometry\strategies\cartesian\distance_projected_point.hpp(99)
>
> assert_dimension_equal<Point, PointOfSegment>();

Is it required to write such function for Geometries with different 
dimensionality?
AFAIR OGC requires the same dimensions and coordinate systems of 
operands, right?
Couldn't dimensions be checked beforehand and some algorithm called only 
if all static asserts shouldn't fail?

<snip>
>> Well we'd be forced to probably use it (only) in not_implemented<>,
>> dispatch::xxx<> and maybe some aditional classes used for reversal of
>> parameters and handling of Variants.
>> But with the approach mentioned above, is this Policy needed?
> Sorry but what alternative are you refering to ?

The one with not_implemented using MPL_ASSERT inside member functions.
If you were able to check if something was supported without raising the 
alarm other Policies wouldn't be needed.
E.g. the algorithm struct at some level of dispatching (right after 
variant was dispatched) could look like the one below.

struct some_algo
{
     template <typename G1, typename G2, typename Strategy>
     static inline void apply(G1 const& g1, G2 const& g2, Strategy const& s)
     {
         typedef dispatch::some_algo<...> algo;
         static const bool version = 
boost::is_base_of<not_implemented_tag, algo>::value
                                  || 
boost::is_base_of<not_implemented_tag, Strategy>::value ? 1 :
                                     // asserts
                                     dimension<G1>::value != 
dimension<G2>::value ? 2 :
                                     // ...
                                     3;

         apply(g1, g2, s, boost::mpl::int_<version>());
     }

private:
     template <typename G1, typename G2, typename Strategy>
static inline void apply(G1 const& g1, G2 const& g2, Strategyconst& s, 
boost::mpl::int_<1>)
     {
         throw some_not_implemented_exception<...>();
     }

     template <typename G1, typename G2, typename Strategy>
static inline void apply(G1 const& g1, G2 const& g2, Strategyconst& s, 
boost::mpl::int_<2>)
     {
         throw some_invalid_dimensions_exception<...>();
     }

     template <typename G1, typename G2, typename Strategy>
static inline void apply(G1 const& g1, G2 const& g2, Strategyconst& s, 
boost::mpl::int_<3>)
     {
         // some assert
         // resolve strategy
         // call the algorithm
     }
};

Well, versions should probably be dispatched with some struct template, 
not on a function level but you get the picture.

>>> I have setup a runtime branch on my fork and will try to add some of my
>>> experiments there to make the discussion less abstract.
>>>
>>> https://github.com/sdebionne/geometry/commit/849fd51679f2cfb22354dab561d4f65b82159a40
> I have update the branch with a test suite for the runtime version of
> distance. Note that the result type is not handled correctly yet. I will
> get inspiration from the length algo that already has variant support
> (and variant result type).
>
>> Thanks for your effort!
> Well, I believe that should be helpfull to implement things like spatial
> extension of SGDB. I'm wondering if the MySQL team has already a
> solution for this...

It's described here:
http://mysqlserverteam.com/making-use-of-boost-geometry-in-mysql-gis/

Regards,
Adam