Geometry Boost List: [ggl] namespace renaming

Subject: [ggl] namespace renaming
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-12-01 03:48:09

>> All library users have to modify sources then, by renaming the used
>> namespace (or using an alias), or renaming macro's.
>>     
>
> I'd add that this is one time operation and for good.
> No more renaming in foreseen future, in case anyone would have doubts.
>   
For the top level namespace, right. But we are not yet there. There was 
a suggestion during review to add namespaces per domain, and therefore 
to move all OGC functions into a separate namespace, on which everyone 
seemed to agree.

boost::geometry::ogc::envelope would be the same as
boost::geometry::cg::bounding_box and
boost::geometry::game::axis_aligned_bounding_box
(these samples are artificial).

So some extra namespaces and code modifications are unavoidable.

It will not be trivial to get a scheme which is satisfactory for 
everyone. 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?
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)

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.

Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091201/aa4772d6/attachment.html