
Geometry : 
Subject: [ggl] namespace renaming
From: Mateusz Loskot (mateusz)
Date: 20091201 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 nonOGC (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
domainspecific equivalents of type/function/module names
which are covered by Boost.Geometry?
If you do, something like this?
 Domainspecific function name equivalent
module 
 generic name  gis/ogc name  gamedev name  ...

io    AsBinary  
io    AsBinary  
e.g. as nonOGC specific but Boost.Geometrywide 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