Boost logo

Boost :

Subject: Re: [boost] [SoC] Summer of Code Project Ideas -- Polygon
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-03-12 23:13:06

Simonson, Lucanus J wrote:
> Mateusz Loskot wrote:
>> I see they are differences. However, I don't see these differences
>> in terms of bad and good choices. I understand well that specifying
>> the requirement of closed polygon is a bad choice in terms of
>> concepts of Boost.Polygon. Though, one may argue that open polygon
>> is a bad choice.
> Open polygon is an equally bad choice. Since there are different
> data types in Boost.Geometry for linestring and ring there is no need
> for the "closed" vertex to signify that a data structure is a
> polygon and not a linestring.

Right, it is a redundancy.

> When I say support polygons that are either open or closed I don't
> mean allow the user to choose one or the other, I mean literally both
> and that algorithms can accept either and are invariant to whether
> the last vertex is duplicate of the first or not.

Yes, I see your point.

>> I'm sure it's feasible, programmatically. What disturbs me,
>> however, changing principle semantics of current design by dropping
>> the winding requirement and closed vs open polygon are
> Barend has already been working on allowing the user to specify the
> winding direction at compile time. What I'm asking is to make it a
> runtime trait of the object and not a complie time trait of the
> class.

I misunderstood you mean compile-time only.

> That way types that know their winding at compile time can return a
> constant and types that don't can return a cached winding direction
> (if they keep it as a data member) or compute it on the fly. This is
> really no more work in the implementation than supporting compile
> time winding trait.

Yes, point taken.

> I want to stress that weakening these semantic requirements for what
> object types can be a model of ring and polygon is not a breaking
> change in the interface of the related concepts. All data types and
> code using Boost.Geometry would still work after the change. What
> the change does is allow additional data types to be used with
> Boost.Geometry that cannot be used today.

Good point. I am reviewing my own considerations regarding this.
Perhaps it will be discussed within Boost.Geometry.
I have forwarded [1] this thread to the Boost.Geometry mailing list


> I want you to interpret my suggestions as constructive feedback on
> ways I think you can make your library interfaces more generic.

I can assure you that I do not interpret your feedback in any other way.
Even if I can't guarantee myself that any changes will happen, I'm
interested in discussing it. I really appreciate you're willing to share
your comments and explain cruxes of the matter to me.

> There are good reasons why we don't require polygon winding to be
> known at compile time and don't require a redundant last vertex in
> CAD applications. It is wonderful that GIS applications can make
> such simplifying assumptions, but unreasonable to expect that
> everyone else can, particularly since the library is named
> Boost.Geometry and not Boost.GIS. I know that a graphics application
> might be really not pleased with storing four points for every
> triangle.

Of course, you are right. I don't mean I appreciated these
simplifications myself. It's more that I've learned to live with them,
what in turn might be narrowing my perception a bit.

Best regards,

Mateusz Loskot,
Charter Member of OSGeo,

Boost list run by bdawes at, gregod at, cpdaniel at, john at