Coverage Referencing

[marqh]

Following on from #35 I have been further investigating ISO 19123:2007

I have a concern regarding this document and Figure 2 - CV_Coverage. I have prepared an abbreviated version of this figure:

This figure defines how a coverage is directly associated with one CRS as defined in ISO19111

However, ISO19111 only presents one way to interface to a CRS:

https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Set%20and%20Metadata.png

The CoordinateSet is the entry point for use of ISO19111 CRS instances. A CoordinateSet is an ordered list of coordinate tuples, each a direct position.

There is nothing that I have seen in 19123 that describes a CV_Coverage as providing a sequence of coordinate tuples, ordered to be consistent with the CRS and only containing those coordinate values that are being referenced.

This, I think, represents a disconnect between 19111 and 19123 and is leading to a number of problems within implementations of 19123 and 19111.
I am concerned that at present the CV_Coverage is associated with the SC_CRS but does not provide the information that SC_CRS expects in the way it is expected. Coordinate tuples are not provided and axis ordering is not explicitly matched to the CRS definition.

For example, a coverage may contain a 2D array if data, with a 1D array of latitudes and a 1D array of longitudes. This may be stored as data(latitude, longitude), ordered for convenience for the data.
Within the scope of the CRS, Axis order is vital, and defined; convention dictates that (longitude, latitude) coordinate pairs are spatially referenced.
There does not appear to be the provision for obtaining a (longitude, latitude) directPosition tuple for each element from the CV_Coverage.

If 19123 CV_Coverage is to have a direct association into 19111's CRS, then I feel it should declare itself as being derived from a 19111 CoordinateSet, so that it is consistent with the 19111 model.
It could also be stated that it should include a method +coordinateTuple() that returns a Sequence of DirectPositions

This could be modelled as follows (perhaps)

There could be numerous ways of dealing with this issue, this is one attempt. My key aim here is to consider and potentially recognise that this is an issue that should be dealt with.

The approach suggested here would enable a coverage to present a dynamically generated CoordinateSet on demand, from the various elements describing individual coverage dimensions.

For example, consider a 5D coverage of 3 spatial, 1 temporal and 1 statistical dimension, where each dimension is defined by a 1d array of coordinate values.
This coverage could define the coordinateTuple method to return an structured array of coordinate tuples, each a (longitude, latitude, altitude, time)
A compound CRS providing referencing for this tuple may then be referenced via the coordinate metadata and there will not be potential confusion about how to interpret aspects such as axis order, as this is explicitly handled by the coordinateTuple method.

[desruisseaux]

In my understanding, this example (5D coverages where each dimension is defined by a 1D array of coordinate values) describes one particular sub-type of CV_Coverage, namely CV_DiscreteGridPointCoverage (even if coordinates are not evenly spaced in 1D arrays) or CV_ContinuousQuadrilateralGridCoverage if we allow interpolations. Those particular coverage subtypes are indirectly associated to a set of CV_GridPoint, which provides a groundPoint attribute giving the representation of the grid point in an external coordinate reference system. The CRS axis order applies here. This provides equivalent functionality to ISO 19111 CoordinateSet but in more indirect way.

I think the reason why the relationship is so indirect is because CV_DiscreteGridPointCoverage is just one particular case of coverage. A coverage may also be a patchwork of geometries (e.g. a coverage of land occupation). CV_DiscreteGridPointCoverage is a particular case of CV_Coverage where the geometries are points or grid cells. Because of that, it is not sure that associating CV_Coverage to CoordinateSet would apply in the general case. A coverage may consist in a set of curves (CV_DiscreteCurveCoverage) for roads, streams, etc.

Note however that even in the general case, CRS axis order is still significant for operations like CV_Coverage.find(DirectPosition).

[desruisseaux]

Note also that I think the association described in the second UML already exists in some way in ISO 19123. In that UML, the CoordinateSet would describe the coverage domain of a CV_DiscreteGridPointCoverage. But CV_Coverage already has a domainElement association to a set of CV_DomainObject. That domain object is specialized by CV_GridPoint. So my guess is that in the particular case of discrete grid point coverage, we can get the groundPoints from the set of CV_GridPoints obtained from CV_Coverage.domainElement.

However I agree that the association from CV_Coverage to SC_CRS may need to be replaced by an association to SC_CoordinateMetadata.

[marqh]

thank you for the feedback on this topic @desruisseaux .

I have looked in some detail into 19123 and attempted to understand how CV_Coverage and CV_DomainObject are to be used.

I continue to view the the relation between the CV_Coverage and the SC_CRS as unclear, in particular with regard to how to present properly ordered coordinate tuples to a SC_CRS (or SC_CoordinateMetadata).

I think that amendments to 19123 are required. Whether these are clarifications and guides, or updates to the model, I do not know. My suggestion to the 19111 group is that we should provide feedback to the 19123 group, with tangible suggestions about how this could be improved.

My attempted interpretation of the models and of feedback from implementers about the issues of coordinate value ordering and axis ordering in CRSs suggests to me that this may be a widespread problem.
I do not think that the interface between 19123 and 19111 is well defined at present and I think some detail suggestions about how this may be improved would bring value.

My initial perspective is that if a CV_Coverage is defined with respect to an SC_CRS, or SC_CoordinateMetadata, then it is the job of the CV_Coverage to ensure that all direct positions, including spatial and temporal aspects, are properly represented as coordinate tuples, prior to providing them to the CRS

At present there appears to be a significant gap between 19123 and 19111 and this is continuing to cause problems, I fear.

[marqh]

I think that the following statement is consistent with 19111:

• A publisher of an identified CRS definition will publish the CRS with a defined CS Axis order.

I am interested whether the following statement is consistent with 19123:

• A coverage, defined with respect to one CRS, will provide referenced coordinate values to the CRS interface as coordinate tuple collections, where each coordinate tuple is ordered consistently with the axis order of the CRS.

My sense based on this ticket, and #35, is that the second statement should be consistent with 19123 and that perhaps 19123 should more clearly mandates this. Perhaps discussing this statement, or an edited version of it, with the 19123 editors would be a useful step?

[desruisseaux]

I'm not sure what mean "provide referenced coordinate values to the CRS interface"? Do we mean something like "Coverage values are defined at positions specified by coordinate values related to Earth by the CRS"?

Instead of "where each coordinate tuple is ordered (…snip…)" I think you mean "where each coordinate value in a tuple is ordered (…snip…)"?

[pebau]

Dear all, re-posting below a typical "datacube" example of a coverage, using 4D coordinates. The connection between coverage and CRS is given by: - CRS identifier in srsName attribute - sequence of labels in axisLabels: for N dimensions there must be N axisLabels, and they will be assigned to each axis in sequence. The names as such do not carry any meaning (starting CIS 1.1) so you can pick any identifier on principle. Coordinates subsequently are identified by the axis label. As coordinates are sorted by axis you will not find one coordinate tuple, but the semantics is well-defined enough to allow for extracting and combining single (x/y/z/t) coordinate tuples at any time. Inset: the axisLabel mechanism strictly speaking could be omitted from an XML perspective, but (i) not all XML systems honour document order and (ii) non-XML encodings usually will need to be explicit about sequence. Here's the example:         <GeneralGrid srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&amp;2=http://www.opengis.net/def/crs/OGC/0/AnsiDate"             axisLabels="Lat Long h date">             <RegularAxis   axisLabel="Lat"  uomLabel="deg" lowerBound="40"  upperBound="60" resolution="10"/>             <RegularAxis   axisLabel="Long" uomLabel="deg" lowerBound="-10" upperBound="10"  resolution="10"/>             <IrregularAxis axisLabel="h"    uomLabel="m">                 <C>  0</C>                 <C>100</C>             </IrregularAxis>             <IrregularAxis axisLabel="date" uomLabel="d">                 <C>2015-12-01</C>                 <C>2015-12-02</C>             </IrregularAxis>             <GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index4D" axisLabels="i j k l">                 <IndexAxis axisLabel="i" lowerBound="0" upperBound="2"/>                 <IndexAxis axisLabel="j" lowerBound="0" upperBound="2"/>                 <IndexAxis axisLabel="k" lowerBound="0" upperBound="1"/>                 <IndexAxis axisLabel="l" lowerBound="0" upperBound="1"/>             </GridLimits>         </GeneralGrid> ...plus a sample WCS request using this for trimming & slicing: http://www.acme.com/wcs ? SERVICE=WCS & VERSION=2.0     & REQUEST=GetCoverage & COVERAGEID=c001     & SUBSET=Long(100,120)     & SUBSET=Lat(50,60)     & SUBSET=time("2009-11-06T23:20:52") HTH, Peter

…

On 01/11/2018 10:42 AM, Martin Desruisseaux wrote: I'm not sure what mean "provide referenced coordinate values to the CRS interface"? Do we mean something like "Coverage values are defined at positions specified by coordinate values related to Earth by the CRS"? Instead of "where each coordinate tuple is ordered (…snip…)" I think you mean "where each coordinate value in a tuple is ordered (…snip…)"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejvXmhrHjkY60ZRWQxuhJVuVxjY6yks5tJddwgaJpZM4RNjoU>.

-- Dr. Peter Baumann - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[pebau]

sorry for the delay - yes, I can confirm that coordinate tuples will be defined via reference to the single CRS of the coverage, in proper axis order. It is just that they are not necessarily stored that way when it comes to implementation (ie, encoding), but there is always a simple and well-defined way to reconstruct the tuples. HTH, Peter

…

On 01/10/2018 05:20 PM, marqh wrote: I think that the following statement is consistent with 19111: * A publisher of an identified CRS definition will publish the CRS with a defined CS Axis order. I am interested whether the following statement is consistent with 19123: * A coverage, defined with respect to one CRS, will provide referenced coordinate values to the CRS interface as coordinate tuple collections, where each coordinate tuple is ordered consistently with the axis order of the CRS. My sense based on this ticket, and #35 <#35>, is that the second statement should be consistent with 19123 and that perhaps 19123 should more clearly mandates this. Perhaps discussing this statement, or an edited version of it, with the 19123 editors would be a useful step? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejpszqFG78Yo71wwSFW-cxdEVEa3dks5tJOM3gaJpZM4RNjoU>.

-- Dr. Peter Baumann - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[marqh]

Hello @pebau

thank you for the examples, they are helpful

I see in the CIS example above
(#39 (comment))
that GeneralGrid contains srsName and axisLabels

Looking at 19123:2007, in particular Figure 2, I cannot see how 19123 provides a framework that this construction conforms to. In particular, I don't understand which part of 19123 defines how to provide axisLabels and how to use these to manage the order of entities within a coordinate tuple for referencing.

Are you able to provide us with any more insights into the 19123 terminology and explain which part of 19123:2007 mandates this kind of representation?
Is this taken from another 19xxx standard or is it explicit in 19123, do you know?

many thanks
mark

[pebau]

Hi @marqh,

in part this is due to a harmonization effort with GML 3.2.1 (among other standards) when CIS was established. But there is also good reason from a technical point: srsName contains the (single) CRS associated with the coverage; although axisLabels (and uomLabels and dimension) are redundant they free the application from looking up a CRS definition (which may affect performance).
You are right, this is not directly inferrable from ISO 19123. In fact, 19123 is quite outdated (has been written ~2000). Therefore, it is under revision by ISO; the successor standard will be named 19123-1, complementing ISO 19123-2 = CIS.
This revision actually sits on my desk staring at me; we managed to get German DIN support, now it has to be produced within 2018.
Hence, it is a good time to express requirements - I already have noted the need for a grid definition, among others.
HTH,
Peter