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

9 Oct 2008

      --------------------------------------------------
From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com>
Sent: Thursday, October 09, 2008 1:00 PM
To: <boost@lists.boost.org>
Subject: Re: [boost] Geometry and spatial indexes, my opinion
...
...
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)
Brandon wrote:
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

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

Brandon Kohn