Hi Martin,<br><br>as a side note, can you provide me some info on the status/working of the Referencing3D module? (I have already downloaded the code but I'm not too familiar with it). Which types of transformations are actually supported? There is some documentation/links on that topic?<br>
I'm investigating a bit into Vertical transformation and I would like to know the effort required to improve 3D/vertical support.<br><br>Thank you very much.<br><br>Regards,<br>Daniele<br><br><div class="gmail_quote">
On Tue, Jun 3, 2008 at 11:00 AM, Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.fr">martin.desruisseaux@geomatys.fr</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Daniele Romagnoli a écrit :<br>
<div class="Ih2E3d">> In this case (ellipsoidal height in vertical extent), since ISO 19111<br>
> states "ellipsoidal heights (h) cannot be captured in a verticalCRS",<br>
> what should VerticalExtent.getVerticalCRS() method return?<br>
<br>
</div>This is an area where ISO and OGC had different views. OGC 01-009 didn't had<br>
this rectriction, and defined explicitly a ellipsoidal datum type. You can see<br>
this historical versions in GeoAPI javadoc:<br>
<br>
<a href="http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#GEOIDAL" target="_blank">http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#GEOIDAL</a><br>
<br>
Note the @UML(specification="...") annotations. We can see that GEOIDAL and<br>
DEPTH (among other) are defined by ISO 19111 while ELLIPSOIDAL was defined by<br>
OGC 01-009. This is an other area (together with MathTransform and others) where<br>
GeoAPI has retrofitted a legacy OGC specification in an ISO one.<br>
<br>
However I have to admit that OGC 01-009 didn't had the concept of a 3D<br>
GeographicCRS, so it may explain why they accepted ellipsoidal VerticalCRS.<br>
<br>
Maybe the ISO intend was to prevent the construction of CompoundCRS as<br>
(GeographicCRS + VerticalCRS) in the ellipsoidal height case. As said in a<br>
previous mail, there is conceptual reasons close to the mathematical nature of<br>
coordinate transformations for that.<br>
<br>
However we have already meet cases where we want to extract the 2D horizontal<br>
component of a 3D GeographicCRS (see the thread about getHorizontalCRS on the<br>
GeoTools mailing list). If we have meet this need for the horizontal part, we<br>
are very likely to meet it for the vertical part as well. I'm more tempted to<br>
allow the expression of the vertical part of a 3D GeographicCRS in isolation,<br>
and rely on the library for making sure that (2D GeographicCRS) + VerticalCRS<br>
are correctly understood as 3D GeographicCRS.<br>
<br>
Note that allowing ellipsoidal VerticalCRS is required anyway for parsing WKT,<br>
since the WKT specification defines 3D GeographicCRS that way. So the last<br>
sentence in the previous paragraph is required anyway for WKT parsing.<br>
<br>
Allowing ellipsoidal VerticalCRS as GeoAPI currently does (in violation with ISO<br>
19111 I admit) allows us to keep more type-safety (like in VerticalExtent),<br>
which is highly desirable. Furthermore I suspect that it would greatly simplify<br>
the task of creating n-D coverage from 2D slices for example.<br>
<br>
So in short, what I'm suggesting is a violation of ISO 19111 restriction against<br>
ellipsoidal VerticalCRS. But I don't think it is a violation of the intend of<br>
that restriction. We could bring this topic at some next OGC meeting (I will<br>
open a JIRA task for that). Does it sound like acceptable for you?<br>
<div><div></div><div class="Wj3C7c"><br>
Martin<br>
<br>
-------------------------------------------------------------------------<br>
This SF.net email is sponsored by: Microsoft<br>
Defy all challenges. Microsoft(R) Visual Studio 2008.<br>
<a href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/" target="_blank">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a><br>
_______________________________________________<br>
Geotools-devel mailing list<br>
<a href="mailto:Geotools-devel@lists.sourceforge.net">Geotools-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/geotools-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/geotools-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-------------------------------------------------------<br>Eng. Daniele Romagnoli <br>Software Engineer<br><br>GeoSolutions S.A.S.<br>Via Carignoni 51<br>55041 Camaiore (LU)<br>
Italy<br><br>phone: +39 0584983027<br>fax: +39 0584983027<br>mob: +39 328 0559267<br><br><br><a href="http://www.geo-solutions.it">http://www.geo-solutions.it</a><br><br>-------------------------------------------------------<br>