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

[Daniele Romagnoli]

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

> Daniele Romagnoli a écrit :
> > Row 358 of ISO 19115:2003/Cor.1:2006 provides a role name "verticalCRS"
> > which is associated to a "SC_CRS" domain. So, it isn't possible to use a
> > SC_CompoundCRS or a SC_EngineeringCRS (both are SC_CRS) for the
> > verticalCRS link? I thought that the specification has should explicitly
> > state "SC_VerticalCRS" instead of "SC_CRS".
>
>
> I forgot this point since it was a while ago... But it is quite possible
> that we
> made the "verticalCRS" association more restrictive in GeoAPI than it was
> in ISO
> specification. But both the association name and the textual description
> suggest
> strongly that VerticalCRS is expected by ISO specification, even if they
> didn't
> expressed this restriction as a VerticalCRS type for unknown reason. We
> note
> also that the ISO 19115 specification before 2003 correction was explicitly
> referencing a VerticalDatum.


Mmm... under this constraint I back to my first question:
how can I expose the extent of the 3rd component of a 3D coverage related to
a GeographicCRS if 19115 spatialBoundingBox allows to handle 2D geographic
coords (n,s,w,e boundaries), and verticalExtent allows to handle the
vertical component except the case of ellipsoidal height (3D
GeographicCRS)?.
I thought linking VerticalExtent to a general SC_CRS would be able to handle
both cases.

Daniele


> Do we have a use case where a user would be right to associate an other
> kind of
> CRS than VerticalCRS to a VerticalExtent? If we wanted to reference a
> generic
> CRS (including CompoundCRS), maybe it would be better located in the Extent
> interface?
>
>        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/21a59493/attachment.html