Geometry Boost List: Re: [geometry] Compiling intersection() after registering custom point for use with the model box, ring and polygon

Subject: Re: [geometry] Compiling intersection() after registering custom point for use with the model box, ring and polygon
From: Andrew Hundt (athundt_at_[hidden])
Date: 2014-05-30 18:45:38

I was able to create a minimal example that reproduces the error, any
suggestions on how to correctly register the models would be greatly
appreciated!

#include <boost/geometry.hpp>

    struct legacy_point

{

    double x, y;

};

BOOST_GEOMETRY_REGISTER_POINT_2D(legacy_point, double, cs::cartesian, x, y)

int main( int /*argc*/, const char** /*argv*/ ){

   boost::geometry::model::polygon<legacy_point> poly;

   boost::geometry::model::ring<legacy_point> ring;

   boost::geometry::model::box<legacy_point> box;

   boost::geometry::intersection(box, ring, poly);

}

Cheers!
Andrew Hundt

On Fri, May 30, 2014 at 6:02 PM, Andrew Hundt <ahundt_at_[hidden]>
wrote:

> Hey Adam,
>
>
> On Fri, May 30, 2014 at 4:27 PM, Adam Wulkiewicz <
> adam.wulkiewicz_at_[hidden]> wrote:
>
>>  Andrew Hundt wrote:
>>
>>  I'm trying to use intersection(box,ring,polygon); in 2D, but I'm
>> getting compiler errors [...]
>>
>>
>>  Can anyone provide advice on what steps I need to take to make sure the
>> intersection call will compile correctly?
>>
>> Isn't [it] that you're trying to call indexing version (working with
>> Boxes and Segments) of set() passing Polygon as parameter? e.g. set<0,
>> 0>(polygon, something); ?
>>
>
> I'm not totally sure what you are asking here, could you rephrase it?
>
> I'll try to answer: I currently have a box and ring for which I need to
> find the intersection. I don't particularly care if I have to convert it to
> a box_view, a ring, or a polygon for the first parameter, or if I have to
> convert the second parameter from a ring to a polygon. I assume the only
> permissible output parameter would be a polygon based on the API of
> intersection().
>
> I'm not exactly sure what the indexing version is, however.
>
>
>> If yes, then this is the problem. The Polygons concept is different, it
>> must be adapted to the RandomAccessRange concept and this way you can
>> access Points.
>>
>> If not, have you noticed also some MPL assert failures?
>>
>
>
> I do actually get an MPL assert failure on struct point_order:
>
> /usr/local/include/boost/geometry/core/point_order.hpp:95:5: No matching
> function for call to 'assertion_failed'
>
> I was a bit surprised by that, since I'm using one of the model types for
> ring. Do customized model types typically have to be registered again?
>
>
> Maybe there is a simple registration call I can make to get past the point
> order registration error?
>
>
>
>> If not, they may be not used in accessors, we should probably think about
>> adding them.
>> Besides, the Point type of this Polygon looks wierd: Coordinate<2, int,
>> Coordinate<2, int, DynamicCellSize<2, Coordinate<2, double, double>, int> >
>> >.
>>
>
> The third parameter in the point type is strictly for type safety, so you
> can define two coordinate types in different coordinate systems that cannot
> interact. That is why it looks weird, but the third parameter doesn't
> actually affect the behavior.
>
>
>>
>> If none of the above helps, could you prepare some minimal failing
>> example?
>>
>
> Perhaps I could give it a shot, but I think I may just need one of those
> registration macros... I'm not sure which, however. Thanks for your help!
>
>
>