|
Geometry : |
Subject: [ggl] namespace renaming
From: Mateusz Loskot (mateusz)
Date: 2009-12-01 16:02:01
Barend Gehrels wrote:
> So some extra namespaces and code modifications are unavoidable.
>
> It will not be trivial to get a scheme which is satisfactory for
> everyone.
That's for sure, but at least we can do what is feasible.
> For OGC it is less complicated, because that is a standard. So
> we will get:
> boost::geometry::ogc::area
> boost::geometry::ogc::centroid
> boost::geometry::ogc::distance
> boost::geometry::ogc::envelope
> etc
>
> For intersection_inserter it is questionable, because the ogc name is
> "intersection" (and that one is planned as well).
> For non-OGC (but normally found together) functions as simplify, where
> will they go?
I see two options, in core/general namespace:
boost::geometry::simplify()
or in the algorithms package, or following my preference,
boost::geometry::algorithm::simplify()
> For a function as "distance", which is probably called "distance"
> everywhere, omit namespace? boost::geometry::distance Or get an alias
> for all domains (probably yes)
Yes.
> I don't have the solution yet, any ideas are welcome. We could start
> creating a list with namespaces covered, and the list on
> http://trac.osgeo.org/ggl/wiki/OGC.
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
Best regards,
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Geometry list run by mateusz at loskot.net