On Fri, May 30, 2008 at 3:51 PM, Martin Desruisseaux <martin.desruisseaux@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.


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


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Geotools-devel mailing list

Eng. Daniele Romagnoli
Software Engineer

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

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