Boost logo

Geometry :

Subject: [ggl] box_range is not a valid range
From: zzsj (feverzsj)
Date: 2011-05-10 06:51:25

hi, Barend
> Thanks again for this - I decided to adopt it, and then processed it a
> bit and merged the implementation (now in views/detail/points_view) with
> segment_range because they were so similar. And then renamed them to
> views, because that was the general idea but not yet done for this. The
> iterators are now private for the ranges, it is not the idea to publish
> them separately as ranges will fullfil the needs (and can be iterated).
> I had to put one thing back for the unit-test, the end-iterator need to
> get a pointer to the points as well, to be able to go to end()-1 (think
> this is not a common use-case but std::vector works like that, and it
> worked like that before).
> So views/box_view.hpp and views/segment_view contain the refactored
> implementations. Additionally the box_view can now also be defined
> counterclockwise (to be specified with an optional template parameter)

Yes, I've seen the changes. The points_view/copy_policy is a good idea for things like box and segment, except the copy_policy seems to make extra copy of the box/segment while being constructed. Is it intended?

Also, now that box_view is of ring type, why it cannot be an opened ring?
The view concept is a kinda confusing concept. It mixes the range and geometry concepts.
I think the view concept should follow the range concept.
As mentioned in "[ggl] transform linestring into a ring", I found two geometry wrappers very useful in many aspects. Here they are:

// warp X as linestring
// X : could be ring, range
// CloseOpenedRing : close presumed opened ring if set to true, otherwise do nothing
template<class X, bool CloseOpenedRing = true>
struct linestring_wrapper;

// warp X as ring
// X: could be linestring, range
template<class X, bool ClockWise = true, bool Closed = false>
class ring_wrapper;

// convenient generators

now, a box_view bv could be either as_linestring(bv) or as_ring(bv), the view concept is then decoupled from geometry concept.
of course, these wrappers could also handle box directly with box_view (since box is ring, we need to know if it is closed/clockwise, so box_view should take care both closure and winding and generate proper range).

regards, ZhouShuangJiang

Geometry list run by mateusz at