Boost logo

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