[Geotools-devel] [Java-collab] ISO19115/ISO19111 VerticalExtent/VerticalCRS and Multidimensional Coverage

[Martin Desruisseaux]

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