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 11:10:54

--------------------------------------------------
From: "Bruno Lalande" <bruno.lalande_at_[hidden]>
Sent: Thursday, October 09, 2008 9:51 AM
To: <boost_at_[hidden]>
Subject: Re: [boost] Geometry and spatial indexes, my opinion

>> Actually in the library I've been working on the definition of the point
>> type is of lesser importance. All of my algorithms are designed to access
>> point coordinates via a traits specialization which details how the 
>> point's
>> coordinates are accessed. It works like this (please excuse email 
>> formatting
>> :)
>
> As said several times by several people including me, it's exactly
> what everybody out there is doing. There's nothing fundamentally new
> in what you propose and in the code you just pasted.
>

The library I've written is the only one in the vault which uses this 
mechanism. Your library in the vault directly accesses the interfaces for 
the underlying points, segments and polygons:

Point: (from intersection_linestring.hpp)

bool clip_segment( const box<PB>& b,
                               segment<PS>& s,
                               bool& sp1_clipped,
                               bool& sp2_clipped) const
{
  typedef typename select_type_traits
  <
        typename PB::coordinate_type,
        typename PS::coordinate_type
  >::type T;
  double t1 = 0;
  double t2 = 1;
  T dx = s.second.x() - s.first.x();///Segment type directly accessed 
followed by call to point interfaces .x()/.y()
  T dy = s.second.y() - s.first.y();
  T p1 = -dx;
  T p2 = dx;
  T p3 = -dy;
  T p4 = dy;
  T q1 = s.first.x() - b.min().x();
  T q2 = b.max().x() - s.first.x();
  T q3 = s.first.y() - b.min().y();
  T q4 = b.max().y() - s.first.y();
...

Polygon:

/*!
\brief Centroid of a polygon.
\note Because outer ring is clockwise, inners are counter clockwise,
triangle approach is OK and works for polygons with rings.
*/
template<typename P, typename Y, typename S>
inline void centroid_polygon(const Y& poly, P& c, const S& strategy)
{
   if (ring_ok(poly.outer(), c))
   {
      typename S::state_type state;
      loop(poly.outer(), strategy, state);//These calls directly access the 
specified type in Y.
      for (typename Y::inner_container_type::const_iterator it = 
poly.inners().begin(); it != poly.inners().end(); it++)
      {
         loop(*it, strategy, state);
      }
      state.centroid(c);
   }
}

This is very different from what I have put up on the vault. I do not 
understand why you don't see this. This code requires the user to either 
wrap their types in an adaptor or translate them into a type which supports 
the interface required by your algorithm implementations. I have looked 
through a lot of this code and it just doesn't do what I am describing. Your 
algorithms here require your points to have x() and y() defined. The segment 
must have first/second for the point access, and the polygon has to have 
outer()/inner().

> That's precisely why I've just said (like you) that the definition of
> a point type in not really important.

I agree that it isn't important, but I don't see how your algorithms will 
work with the fusion example I have put up.

>
> Bruno

Sincerely,

Brandon

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