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

[Daniele Romagnoli]

Hi Martin,

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?
I'm investigating a bit into Vertical transformation and I would like to
know the effort required to improve 3D/vertical support.

Thank you very much.

Regards,
Daniele

On Tue, Jun 3, 2008 at 11:00 AM, Martin Desruisseaux <
martin.desruisseaux at geomatys.fr> wrote:

> 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
> Geotools-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>



-- 
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267


http://www.geo-solutions.it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/java-collab/attachments/20080603/92dcb8d7/attachment.html