Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-20 08:51:39

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