[Geotools-devel] [Java-collab] ISO19115/ISO19111
VerticalExtent/VerticalCRS and Multidimensional Coverage
Martin Desruisseaux
martin.desruisseaux at geomatys.fr
Tue Jun 3 05:00:06 EDT 2008
Daniele Romagnoli a écrit :
> In this case (ellipsoidal height in vertical extent), since ISO 19111
> states "ellipsoidal heights (h) cannot be captured in a verticalCRS",
> what should VerticalExtent.getVerticalCRS() method return?
This is an area where ISO and OGC had different views. OGC 01-009 didn't had
this rectriction, and defined explicitly a ellipsoidal datum type. You can see
this historical versions in GeoAPI javadoc:
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#GEOIDAL
Note the @UML(specification="...") annotations. We can see that GEOIDAL and
DEPTH (among other) are defined by ISO 19111 while ELLIPSOIDAL was defined by
OGC 01-009. This is an other area (together with MathTransform and others) where
GeoAPI has retrofitted a legacy OGC specification in an ISO one.
However I have to admit that OGC 01-009 didn't had the concept of a 3D
GeographicCRS, so it may explain why they accepted ellipsoidal VerticalCRS.
Maybe the ISO intend was to prevent the construction of CompoundCRS as
(GeographicCRS + VerticalCRS) in the ellipsoidal height case. As said in a
previous mail, there is conceptual reasons close to the mathematical nature of
coordinate transformations for that.
However we have already meet cases where we want to extract the 2D horizontal
component of a 3D GeographicCRS (see the thread about getHorizontalCRS on the
GeoTools mailing list). If we have meet this need for the horizontal part, we
are very likely to meet it for the vertical part as well. I'm more tempted to
allow the expression of the vertical part of a 3D GeographicCRS in isolation,
and rely on the library for making sure that (2D GeographicCRS) + VerticalCRS
are correctly understood as 3D GeographicCRS.
Note that allowing ellipsoidal VerticalCRS is required anyway for parsing WKT,
since the WKT specification defines 3D GeographicCRS that way. So the last
sentence in the previous paragraph is required anyway for WKT parsing.
Allowing ellipsoidal VerticalCRS as GeoAPI currently does (in violation with ISO
19111 I admit) allows us to keep more type-safety (like in VerticalExtent),
which is highly desirable. Furthermore I suspect that it would greatly simplify
the task of creating n-D coverage from 2D slices for example.
So in short, what I'm suggesting is a violation of ISO 19111 restriction against
ellipsoidal VerticalCRS. But I don't think it is a violation of the intend of
that restriction. We could bring this topic at some next OGC meeting (I will
open a JIRA task for that). Does it sound like acceptable for you?
Martin
More information about the Java-collab
mailing list