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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
