
Boost : 
Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 20091120 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 > metafunction 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
metafunction 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk