[Geoserver-devel] ISO19115/ISO19111 VerticalExtent/VerticalCRS and Multidimensional Coverage

GeoServer GeoServer Developer
1

Hi lists,
I have another question about VerticalExtent.
As already stated in my previous email titled “Multidimensional Coverage and Vertical Extent”, part of my job is related to handling the Extent of a 4D Coverage (XY+Vertical+Temporal). In such a context, ISO 19115 defines the EX_Extent element which is extended by GeographicBoundingBox (holding northing,southing,westing,easting geographic boundaries), TemporalExtent and VerticalExtent. The latter is related to a 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?
I just have acquired the 19115:2003 corrigendum 2006 which, for VerticalExtent, has removed the verticalDatum element changed to verticalCRS. Consequently SC_VerticalDatum class has been changed to SC_CRS with the note “SC_CRS: set of parameters describing the relation of gravity-related heights to the Earth”.
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)?
Maybe the ISO 19115 VerticalExtent could be related to a more general CoordinateReferenceSystem within it lives instead of a VerticalCRS.

Best Regards,
Daniele

–

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

2

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.

(...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

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()

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()

  Martin

3

Hi Martin,

On Fri, May 30, 2008 at 1:03 PM, Martin Desruisseaux <martin.desruisseaux@anonymised.com> 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


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()

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()

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@anonymised.coms.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

4

Daniele Romagnoli a écrit :

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?

VerticalExtent can be linked to a VerticalCRS through the VerticalExtent.getVerticalCRS() method, and the opposite way is possible too through the VerticalCRS.getExtent() method. But I'm not sure to understand the issue. You would like to link VerticalExtent to a CompoundCRS rather than VerticalCRS? Current API do not allows that since the link is rectricted to VerticalCRS type...

However CompoundCRS can be linked to an Extent, and giving an Extent we can invokes getVerticalElements() for fetching the VerticalExtents, and invoke getVerticalCRS() on those. Would it be applicable?

  Martin

5

On Fri, May 30, 2008 at 2:40 PM, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

Daniele Romagnoli a écrit :

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?

VerticalExtent can be linked to a VerticalCRS through the
VerticalExtent.getVerticalCRS() method, and the opposite way is possible too
through the VerticalCRS.getExtent() method. But I’m not sure to understand the
issue. You would like to link VerticalExtent to a CompoundCRS rather than
VerticalCRS? Current API do not allows that since the link is rectricted to
VerticalCRS type…

When in my previous email I have expressed my doubt about the SC_CRS meaning, I was indeed talking about this constraint.
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”.

Regards,
Daniele

However CompoundCRS can be linked to an Extent, and giving an Extent we can
invokes getVerticalElements() for fetching the VerticalExtents, and invoke
getVerticalCRS() on those. Would it be applicable?

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@anonymised.coms.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

6

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.

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

7

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

8

Daniele Romagnoli a écrit :

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)?.

ISO 19111 said that "GeographicCRS + VerticalCRS" should be illegal if the VerticalCRS is height about ellipsoid, but I don't think that this restriction needs to apply to Extent too...

The "3D Geographic" special case exists for mathematical reason during coordinate transformation. Those mathematical reasons do not apply to Extent as far as I can see, and I don't remember to have seen such restriction in ISO.

So I would suggest to store the 3rd component as a VerticalExtent like any kind of height (no special case for ellipsoidal height), create a Extent containing the GeographicBouindingBox + VerticalExtent, and gives this Extent to GeographicCRS ("ellipsoidal height" case) or CompoundCRS ("other height" case) constructor.

Is it in the direction of what you are looking for?

  Martin

9

Hi Martin,
sorry for the late reply. Please, read below…

On Fri, May 30, 2008 at 5:55 PM, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

So I would suggest to store the 3rd component as a VerticalExtent like any kind
of height (no special case for ellipsoidal height), create a Extent containing
the GeographicBouindingBox + VerticalExtent, and gives this Extent to
GeographicCRS (“ellipsoidal height” case) or CompoundCRS (“other height” case)
constructor.

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?

Cheers,
Daniele

Is it in the direction of what you are looking for?

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@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

10

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

11

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@anonymised.com> 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@anonymised.coms.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

12

Hello Daniele

Daniele Romagnoli a écrit :

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.

Referencing3D provides a MathTransform implementation capables to perform the following vertical height transformation:

    Geoidal height (WGS84) <----> Ellipsoidal height (WGS84)
    Geoidal height (WGS80) <----> Ellipsoidal height (WGS80)

This part is done (more tests are always welcome).

Now the hard part is actually in the referencing module itself, more specifically in the following class which is the one trying to figure out the MathTransform chain by itself given a (sourceCRS, targetCRS) pair:

http://javadoc.geotools.fr/snapshot/org/geotools/referencing/operation/DefaultCoordinateOperationFactory.html

This work is non-trivial and requires a good knowledge of DefaultCoordinateOperationFactory working...

  Martin