Every 3D CRS except one special case (more on it later) are handled like that:
a CompoundCRS made of a horizontalCRS + a VerticalCRS. Example: ProjectedCRS + VerticalCRS of kind "height above the ellipsoid" ProjectedCRS + VerticalCRS of kind "height above the geoid" GeographicCRS + VerticalCRS of kind "height above the geoid" All the above are CompoundCRS (well, maybe it would be possible to handle the first one as a 3D ProjectedCRS, but ISO 19111 do not make any requirement about that. Lets said that it is a CompoundCRS as well for keeping things simplier). There is one and only one exception, which is explicitly mandated by ISO 19111: GeographicCRS + VerticalCRS of kind "height above the ellipsoid" According ISO 19111, This one must NOT be express as a CompoundCRS, but shall always be express as a 3D GeographicCRS instead (thats said a GeographicCRS associated to a 3D EllipsoidalCS). There is mathematical reasons for this exception. To make a short story, such 3D GeographicCRS is a kind of pivot when applying datum shift, and we must ensure that this pivot exists. So if we read ISO 19111 literaly, a CompoundCRS made of GeographicCRS + ellipsoidal height is not allowed. In practice, I have found that it is often desirable to be able to handle such CRS as if it was a CompoundCRS (i.e. splittable). This is why GeoAPI make a departure compared to ISO 19111 on this one. Such kind of departure are identified in GeoAPI javadoc using a @departure javadoc tag. http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#ELLIPSOIDAL We have provided a few convenience methods in org.geotools.referencing.CRS class for splitting an arbitrary CRS to its horizontal and vertical components. Those convenience methods have not be extended up to the point they can handle the special case of 3D GeographicCRS, but this is a user request so we will do that when time allows. http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#getVerticalCRS(org.opengis.referencing.crs.CoordinateReferenceSystem) As for other kind of height like "sigma level" (the ratio between sea surface and the ocean floor), it is theorically possible to create a CompoundCRS made of a GeographicCRS and whatever kind of CRS we want (could be a measure of pressure). We do not have an explicit class for height like "sigma level", but I have heard that future revision of ISO 19111 will contains a "FunctionCRS" or something like that. > I was interested by this statement in the javadoc for > DefaultVerticalCRS: "ellipsoidal heights (h) cannot be captured in a > vertical coordinate reference system. Ellipsoidal heights cannot exist > independently, but only as inseparable part of a 3D coordinate tuple > defined in a geographic 3D coordinate reference system." However, the > DefaultVerticalCRS class itself has the ELLIPSOIDAL_HEIGHT property (a > 1D vertical CRS), which would seem to contradict this statement. > Should the ELLIPSOIDAL_HEIGHT CRS be used with caution? Is it an > approximation? The statement should be relaxed. DefaultVerticalCRS was first wrote in strict ISO 19111 compliance, then we realized that a relaxation was required (WKT parsing alone was already a strong reason as explained in the "departure from ISO 19111" comment in GeoAPI), so we added that DefaultVerticalCRS and I forgot to update DefaultVerticalCRS comment accordingly. Thanks for spotting that. > On a related note, is DefaultGeographicCRS.WGS84_3D an inseparable 3D > CRS? Or is it a combination of WGS84 + ELLIPSOIDAL_HEIGHT? In other > words, is the interpretation of the ellipsoidal height dependent upon > latitude and longitude? Or are all three axes orthogonal? It depends what you want to do. DefaultGeographicCRS.WGS84_3D is separable (it is just a more complicated operation than CompoundCRS, and our CRS.getHorizontal/VerticalCRS convenience methods to do yet handle those case if I remember right). Whatever the interpretation ellipsoidal height dependent upon latitude and longitude or not depends of what you want to do. When applying a coordinate operation, they can be treated as orthogonal only if the operation do not involves a datum shift. For example they can be treated as orthogonal in map projection, assuming the target ProjectedCRS uses the same datum than the source GeographicCRS. However if there is a datum shift (WGS84 to Clarke, etc.), then the 3 axis must be handled together; they can not be separated. Transforming (40°N 30°W 10m) and (40°N 30°W 1000m) will gives slightly different results even for the horizontal part alone. Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
