Subject: [ggl] namespace renaming
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-12-03 04:18:52
Hi,
> I see two options, in core/general namespace:
> boost::geometry::simplify()
> or in the algorithms package, or following my preference,
> boost::geometry::algorithm::simplify()
>
The last one should be there for sure. I don't know if it is necessary
to make non-namespace aliasses as well...
About singular / plural, yes, I agree. We do have that convention
already (e.g. namespace boost::geometry::strategy), so it fits.
The namespace geometry is then a little unfortunate because we already
use that namespace. boost::geometry::geometry would be too much and
confusing.
However, geometries are in fact "geometric shapes", this definition is
more precise because geometry is "the part of mathematics ..." (wikipedia).
So I propose namespace shape for the neutrally-named collection of shapes.
We then get:
boost::geometry::shape::point<...> // as we have it now in boost::geometry
boost::geometry::shape::polygon<...> // as we have it now in
boost::geometry, dim agnostic, orientation agnostic, (todo: flexible on
closeness-agnostic)
boost::geometry::ogc::point // to define an OGC point
boost::geometry::ogc::polygon // defines an OGC polygon, clockwise, closed
>
> A list with namespaces? Do you mean a matrix of
> domain-specific equivalents of type/function/module names
> which are covered by Boost.Geometry?
>
> If you do, something like this?
>
> | Domain-specific function name equivalent
> module --------------------------------------------------
> | generic name | gis/ogc name | gamedev name | ...
> ---------------------------------------------------------
> io | --- | AsBinary | ---
> io | --- | AsBinary | ---
>
>
> e.g. as non-OGC specific but Boost.Geometry-wide Wiki:
>
> http://trac.osgeo.org/ggl/wiki/Names
>
Yes, such a page would be very good!
Regards, Barend