Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-02-26 14:12:51

Luke wrote:
>> it is also unreasonable to assume a winding direction convention. 
>> If your polygon concept requires these three conditions (not empty,
>> closed and CC winding) you are excluding 7/8 legacy data types if we
>> assume each decision is made arbitrarily.   

Barend Gehrels wrote:
> We assume closed polygons with specific windings in our algorithms.
> For Legacy-polygons we provide the "correct" algorithm.

You cannot "correct" a polygon type that enforces the class invariant that the polygon is not-closed or has opposite winding of your convention.
Such practice is considered good object oriented design, and is common.  More than half of the polygon object I'm familiar with enforce winding, but do so with arbitrary decision of which winding they enforce.  Such polygons cannot model your polygon concept, and will be copy converted to something that does (such as your polygon data type) to satisfy the requirements of your library API.  This defeats the purpose of C++ concepts based geometry API design.  Requiring the user data types conform to these semantics fails to create a general interface for polygon objects.  It may be possible for a motivated user to create interfaces in their polygon traits specialization that would iterate over their polygon in reverse order and tack on an extra point for wrap-around closed semantics.  I could do that easily, but I don't think it is reasonable to expect that of a geometry library user as opposed to geometry library author.  It requires extra programming effort to setup the traits and also a lot more knowledge and understanding of the semantics requried of polygons by the library.  Such attempts are likely to fail on the first try.  It is likely to lead to users resorting to copy conversion.  I believe design decisions should lead to a library that is convenient to use rather than convenient to implement.  Assuming the winding direction and closed semantic is a convenience for implementing the algorithms only.  These minor semantic differences are the swamp of geometry data type conversion.  The library should elevate the user above these low level annoyances and allow them to work at a higher level of abstraction, not force them to trudge through the swamp the same way they always have in the past to use every other geometry library.

I also want to reiterate that area(point) and length(polygon) should be syntax errors.  Type safety isn't something we should break lightly.

Regards,
Luke