<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I have one minor suggestion. In <tt>crs.hh</tt> file, there is
the following comment in the <tt>GeodeticCRS</tt> class:</p>
<blockquote>
<pre>// slight departure from standard. We can't override coordinateSystem() since
// GeographicCRS::coordinateSystem() returns cs::EllipsoidalCS which is not
// derived from GeodeticCS (GeodeticCS is a pseudo union) ...
const cs::GeodeticCS &geodeticCoordinateSystem() const;
</pre>
</blockquote>
<p>I would suggest to not try too hard to represent verbatim the «
union » constructs from ISO 19111, but rather focus on the intent.
With this <tt>GeodeticCS</tt> « union », ISO 19111 is trying to
said that a <tt>GeodeticCRS</tt> shall be associated only to an <tt>EllipsoidCS</tt>,
<tt>CartesianCS</tt> or <tt>SphericalCS</tt>. If it is possible
to express this constraint in the C/C++ language (with C <tt>union</tt>
or whatever other construct may fit), good! If it is not
practical, then I think it is okay to just state the constraint in
the documentation. This is what we have done in Java for instance.
Having a second property returning a "CS-like" object gives the
impression that <tt>SingleCRS</tt> can be associated to two
coordinate systems, which may be confusing.<br>
</p>
<p>Note: ISO 19111 do not define <tt>GeodeticCS</tt> as a parent of
<tt>EllipsoidCS</tt>, <tt>CartesianCS</tt> and <tt>SphericalCS</tt>
because conceptually, "GeodeticCS" is not really a kind of
coordinate system. Another reason is that such hierarchy would be
very specific to <tt>GeodeticCRS</tt> needs and may fit the needs
of other CRS.</p>
<p> Martin</p>
<p><br>
</p>
</body>
</html>