Re: [boost] Geometry and spatial indexes, my opinion

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2008-10-09 15:12:25

--------------------------------------------------
From: "Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]>
Sent: Thursday, October 09, 2008 1:00 PM
To: <boost_at_[hidden]>
Subject: Re: [boost] Geometry and spatial indexes, my opinion

> Brandon wrote:
>>I posted this to clarify how I implemented the ideas for Patrick or
> anyone
>>else who was confused by my post. I think it is relevant because a)
> there
>>are many long threads in the archive on geometry which are difficult to
>
>>follow (so the points may be hard to uncover.)  and b) I couldn't find
> any
>>where someone has committed to this exact mechanism.
>
> You have access to the boost svn sandbox, which has my recent code.  My
> library in the vault is fairly out of date.  Below I am registering
> legacy point and polygon classes with my geometry library so that I know
> their conceptual type for tag dispatching purposes:
>
>  template <>
>  struct geometry_concept<CCGCoordPoint> {
>    typedef point_concept type;
>  };
>
>  template <>
>  struct geometry_concept<CPolygonQuery> {
>    typedef polygon_concept type;
>  };
>
> And here I specify the traits of the legacy point type such that I know
> what coordinate type it uses and how to access its data.  I have runtime
> accessor instead of compile time because we like to use orientation as
> runtime data instead of compile time constant in our code.  Construct is
> not strictly necessary because I could use default construction and set
> x and y.
>
>  template <>
>  struct point_traits<CCGCoordPoint> {
>    typedef intDC coordinate_type;
>
>    static inline coordinate_type get(const CCGCoordPoint& point,
> orientation_2d orient) {
>      return point.Coord()[orient.to_int()];
>    }
>    static inline void set(CCGCoordPoint& point, orientation_2d orient,
> coordinate_type value) {
>      point.Coord()[orient.to_int()] = value;
>    }
>    static inline CCGCoordPoint construct(coordinate_type x_value,
> coordinate_type y_value) {
>      return CCGCoordPoint(x_value, y_value);
>    }
>  };
>
> And here I'm defining the traits for the legacy polygon which uses the
> legacy point as part of its interface.  Specifically, pointer to legacy
> point type models an iterator semantic of objects that are conceptually
> points.
>
>  template <>
>  struct polygon_traits<CPolygonQuery> {
>    typedef intDC coordinate_type;
>    typedef const CCGCoordPoint* iterator_type;
>
>    /// Get the begin iterator
>    static inline iterator_type begin(const CPolygonQuery& t) {
>      return t.Data();
>    }
>
>    /// Get the end iterator
>    static inline iterator_type end(const CPolygonQuery& t) {
>      return t.Data() + t.GetSize();
>    }
>
>    /// Set the data of a polygon with the unique coordinates in an
> iterator, starting with an x
>    template <typename iT>
>    static inline CPolygonQuery& set(CPolygonQuery& t, iT input_begin,
> iT input_end) {
>      std::vector<intDC> pts;
>      for(; input_begin != input_end; ++input_begin) {
>        pts.push_back(point_concept::get((*input_begin),
> gtl::HORIZONTAL));
>        pts.push_back(point_concept::get((*input_begin),
> gtl::VERTICAL));
>      }
>      t.SetPolygon(t.GetLayer(), pts.size()/2, &(pts[0]));
>      return t;
>    }
>
>    /// Get the number of sides of the polygon
>    static inline unsigned int size(const CPolygonQuery& t) {
>      return t.GetSize();
>    }
>
>    /// Get the winding direction of the polygon
>    static inline winding_direction winding(const CPolygonQuery& t) {
>      return unknown_winding;
>    }
>  };
>
> I did the interface this way for exactly the same reason that you did.
> I have to interact with a large number of legacy geometry type systems
> in proprietary code.  By the way, I have every respect for what you have
> done, if there is anyone in the world who can really appreciate your
> library you have found them here.
>
> Luke

Hi Luke,

I agree that this is certainly similar to what I have and that it is very 
good. There is however a distinction in that the access traits in my design 
are separate from the general point traits. I think that this is an 
important distinction. When you strip a basic point in N dimensions from any 
nomenclature, you essentially have a data structure that can be describing a 
location in any coordinate frame of dimension N. It is only through choosing 
a coordinate frame that the dimensions of the point takes on meaning (well, 
strictly speaking this isn't true... I have a text that speaks quite highly 
of coordinate free geometry..). This is why I have created access traits 
which are aligned with a particular coordinate frame. It gives me the means 
to have a legacy point type (which uses a particular framework, polar 
coordinates) which can then automatically work in an algorithm which 
requires Cartesian coordinates. By specializing an access traits type for 
the legacy point, I can make all required transformations from r, theta to 
x,y without doing any explicit translations to the underlying point type. 
The result is that I can put my polar points in and still use all these 
great algorithms which require Cartesian coordinates. Also any outputs or 
modifications to inputs are automatically written back in polar coordinates 
due to the same interface (via the construct method of the access traits.)

Cheers,

Brandon

> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>