|
Geometry : |
Subject: Re: [geometry] Compiling intersection() after registering custom point for use with the model box, ring and polygon
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-05-30 16:27:16
Hi,
Andrew Hundt wrote:
>
>
> I'm trying to use intersection(box,ring,polygon); in 2D, but I'm
> getting compiler errors that I think are tied to registration. I'm
> using a boost::geometry::model::* for the box, ring and polygon in
> this call with a custom coordinate type. I had assumed that models for
> box, ring, and polygon don't need to be registered. Perhaps that is
> not correct?
>
>
> The coordinate is defined as follows:
>
> template<size_t Dim, typename T, typename U = T>
>
> struct Coordinate;
>
>
> I register the tag, dimension, coordinate_type, and coordinate_system,
> but I think the most relevant component tied to this error is when I
> register the coordinate's 'get()' and 'set()' functions as follows
> (apologies if the email client messes with spacing):
>
>
> template<size_t Dim, typename T, typename U, size_t Index, typename
> Enable>
>
> struct access<Coordinate<Dim,T,U> , Index, Enable>
>
> {
>
> static inline typename Coordinate<Dim,T,U>::value_type
> get(Coordinate<Dim,T,U> const& p) { return p.operator[](Index); }
>
> static inline void set(Coordinate<Dim,T,U> & p, typename
> Coordinate<Dim,T,U>::value_type const& value) { p.operator[](Index) =
> value; }
>
> };
>
>
> Here is the error:
>
> /usr/local/include/boost/geometry/core/access.hpp:393:24: No member
> named 'set' in
> 'boost::geometry::core_dispatch::indexed_access<boost::geometry::polygon_tag,
> boost::geometry::model::polygon<Coordinate<2, int, Coordinate<2, int,
> DynamicCellSize<2, Coordinate<2, double, double>, int> > >, true,
> true, std::vector, std::vector, std::allocator, std::allocator>, int,
> 0, 0, boost::integral_constant<bool, false> >'
>
>
>
> Can anyone provide advice on what steps I need to take to make sure
> the intersection call will compile correctly?
>
Isn't 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); ?
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?
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> > >.
If none of the above helps, could you prepare some minimal failing example?
Regards,
Adam
Geometry list run by mateusz at loskot.net