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