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://listarchives.boost.org/mailman/listinfo.cgi/boost
>