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

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2009-02-26 16:52:25

On Thu, Feb 26, 2009 at 4:26 PM, Barend Gehrels <barend_at_[hidden]> wrote:
>
> (source: http://www.opengeospatial.org/standards/sfa#downloads)
>
> I'm talking about OGC more on this list. They have defined a well-defined
> interface which is followed by the majority of the GIS world and which is
> based on a mathematical/topological foundation. So we better follow their
> guidelines than take decisions about every possibility ourselves. Most if
> not all Open Source implementations are following these rules.

Might I suggest that since you are aiming for OGC compliance, and from
your recent mention of including coordinate system projections, that
you narrow your library's focus into something more like Boost.GIS
instead of Boost.Geometry?

> Of course we can concentrate on making polygons "winding-agnostic" and
> "closing-point-agnostic". I'm not convinced however that that is so easy. If
> you calculate a convex hull, do you want it returned in the same winding
> direction as you defined it? It will have an influence, plus a performance
> malus, on many algorithms. By just providing the "correct" algorithm we
> enable library users to use our library with every polygon. It cannot be
> called from the algorithms themselves: to verify the winding rule the area
> has to be calculated beforehand. This will drastically decrease performance.
>
> The solution might be a traits class telling the winding rule the polygon
> type has. That might be ever implemented, but for now we'll better
> concentrate on other things. Same for closing point.

GIS is my work area, so I know it's huge, but it seems like you are
trying to tackle GIS + generic geometry library.  I don't get the
impression that game programmers, for example, will enjoy or use this
library.  Polygons are not closed (and rarely used, only triangles
are) in games, and cannot have holes, and any error checking to
determine otherwise is wasteful.  Winding is handled by the rendering
API, and is also rarely, if ever, checked since the model exporter
will have enforced the correct winding.

It seems easier to please one group of people (GIS) than to try to
please GIS, scientific simulations, game, CAD developers, and more.  I
believe it will also lead to less discussion about the correctness of
interfaces since there is already a standard (OGC) to back you up if
you choose GIS.  Choose none of them, and you'll have programmers from
all industries telling you why your way is wrong and their way is
right.

--Michael Fawcett

P.S. I would love to start using a really fast and elegant Boost.GIS
rather than ESRI ArcObjects...