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

[Daniele Romagnoli]

Hi Martin,

On Fri, May 30, 2008 at 1:03 PM, Martin Desruisseaux <
martin.desruisseaux at geomatys.fr> wrote:

> Hello all
>
> Daniele Romagnoli a écrit :
> > (...snip...)
> > VerticalCRS (as defined in 19111) which can't be used to handle
> > ellipsoidal height since this height only lives within a 3D
> GeographicCRS.
> > Under these conditions, how should I handle the 3rd component of a
> > GeographicCRS to follow the 19115/19111?
>
> As far a 19111 is concerned, 3D and 4D CRS should be handle as CompoundCRS.
> Or
> to be more specific, you need to build an array on SingleCRS of length 2 or
> 3:
>
> General case *except* GeographicCRS with ellipsoidal height:
> ------------------------------------------------------------
> SingleCRS[] components = new SingleCRS[] {
>     horizontalCRS, // Typically a 2D GeographicCRS or a ProjectedCRS
>     verticalCRS,
>     temporalCRS
> };
>
>
> Special case for a GeographicCRS with ellipsoidal height:
> ------------------------------------------------------------
> SingleCRS[] components = new SingleCRS[] {
>     geographicCRS,  // Shall be 3D.
>     temporalCRS
> };
>
>
> Then, give this array to the CompoundCRS constructor.
>

Yes, this is the approach I thought to use.


>
>
>
> > (...snip...)
> > Now I'm not sure about the meaning of that SC_CRS. It is referring to a
> > general CRS containing a "height related" component (Such as a 3D
> > GeographicCRS or a CompoundCRS)?. Or the SC_CRS has been used to
> > indicate the base class of a VerticalCRS to point out that the Datum
> > class is no more needed)?
>
> The SC_CRS object mentioned in ISO 19111/19115 is called
> CoordinateReferenceSystem in GeoAPI. This mapping between the GeoAPI name
> and
> the original ISO 19111 name is documented in the following annotation:
>
> @UML(identifier="SC_CRS", specification=ISO_19111)
>
> which appears just before the class declaration:
>
>
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/crs/CoordinateReferenceSystem.html


Sorry, I have badly expressed my doubts about the CRS role in the Vertical
context and maybe I was too brief.
Can I "link" the VerticalExtent to a CompoundCRS (extending SC_CRS) which
should contain a GeographicCRS or a VerticalCRS, to identify the CRS of this
vertical extent?

Regards,
Daniele


>
> <http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/crs/CoordinateReferenceSystem.html>
> Actually the naming and class hierarchy in ISO specifications are a little
> bit
> convolved regarding that "CRS" class for historical reasons (compatibility
> and
> interoperability between ISO 19111 and ISO 19115 because the later defined
> objects that duplicate ISO 19111).
>
> VerticalCRS extends CoordinateReferenceSystem and thus inherit a datum
> field.
> You can invoke VerticalCRS.getDatum() in order to get the VerticalDatum.
>
>
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/crs/VerticalCRS.html#getDatum()<http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/crs/VerticalCRS.html#getDatum%28%29>
>
> > Maybe the ISO 19115 VerticalExtent could be related to a more general
> > CoordinateReferenceSystem within it lives instead of a VerticalCRS.
>
> ISO 19111 defines a "domain of validity" for every
> CoordinateReferenceSystem. So
> it is possible to invoke VerticalCRS.getDomainOfValidity() in order to get
> an
> Extent. Whatever this extent is relevant or not is left to
> implementations...
>
>
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/ReferenceSystem.html#getDomainOfValidity()<http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/ReferenceSystem.html#getDomainOfValidity%28%29>


>
>
>        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/20080530/245fec79/attachment-0001.html