<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 &amp;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>