#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);
}
Hey Adam,On Fri, May 30, 2014 at 4:27 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:Andrew Hundt wrote: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 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?
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!