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
[1] http://lists.osgeo.org/pipermail/ggl/2010-March/000675.html
> 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, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org