Hi Brandon, Thanks for your thorough review. A few remarks and answers on some of your points.
Which seems to be a way to specify a unit type for angular coordinates. I'm not sure how such a construct extends into other unit types such as feet/meters on distance coordinates.
We did address it (it is in the EPSG system, which is in the GIS extension and was not in the Formal Review). So you are right, it was not clear. It works like this: template<std::size_t Code> struct epsg { static const std::size_t epsg_code = Code; }; template <std::size_t C> struct cs_tag<cs::epsg<C> > { typedef cartesian_tag type; }; So any epsg geometry is classified as the cartesian coordinate system family (btw, that can be doubted, because latlong does also has an EPSG code, but in general projections are cartesian coordinate systems, uniquely numbered by EPSG). Units are not in this example (though projections have units, usually meters) but you could implement them similarly, and indeed, using Boost.Units might be an option here.
Further to this I found a type trait struct 'is_radian<T>' but none for 'is_degree' (or is_meter, is_feet). I think these artifacts will present issues if the geometry library were to be later abstracted to support units on the coordinate types. is_radian is used internally to know if spherical coordinates should be converted to radians, because all math calculations are done in radians. It is therefore necessary to know it. We didn't consider is_degree or is_meter necessary; if all coordinate systems have units, we probably should add another traits to define that.
The geometry concepts seem sound at a glance, but I wonder how they would fare in the light of extension. For example, the ggl::point_type< Geometry > meta-function would seem to presume that all geometries have an underlying point representation.
Good point. It seems also not strictly necessary for a box defined like: struct box { double ul,ll,ur,lr; }. There is no point used here, but the meta-function should still be defined for a box, just because a point type is used in, probably all algorithms. We cannot do without, at least, currently we cannot.
I don't think this consortium is widely recognized as a standard for geometry names in general.
We perfectly understand your point. Michael suggested namespaces on your point, seconded by Pierre. We consider this as a perfect solution to support different domains with different naming conventions, etc. OGC conventions (at least most of them) are shared by OGC, ISO (a.o. SQL/MM). http://www.ogcnetwork.net/node/398#_Toc206572745
Over the course of my professional career I have worked on 2 geometry libraries.
Again, you certainly have many things to add, as you stated somewhere else. Let me repeat that you're welcome to contribute, probably I can state this, to a boost geometry library, one, (in case GGL is accepted:) other, both, or in its cooperation. Regards, Barend