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

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