On Fri, May 30, 2008 at 3:51 PM, Martin Desruisseaux <email@example.com
Daniele Romagnoli a écrit :
> Row 358 of ISO 19115:2003/Cor.1:2006 provides a role name "verticalCRS"I forgot this point since it was a while ago... But it is quite possible that we
> 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".
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