Re: [boost] [SoC] Summer of Code Project Ideas -- Polygon

Subject: Re: [boost] [SoC] Summer of Code Project Ideas -- Polygon
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-03-11 18:19:37

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.  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. 

> 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.  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.  The open vs. closed issue is similar, and the primary implication of these changes is that you have to test your algorithms for these cases, since the changes in their implementation will typically be small.

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.  I want you to interpret my suggestions as constructive feedback on ways I think you can make your library interfaces more generic.

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.

Thanks,
Luke