Providing Coverage Advice

[marqh]

I have been investigating how coverages may use 19111 CRS instances. I believe there is a degree of expectation on the 19111 group to provide input to the 19123 editing team on this topic.

I have prepared a set of object diagrams, based on the class diagrams in this repository. I will put these in individual comments, with a commentary alongside each one.
These show how a set of objects, instances of the classes, may be used to define a specific scenario
(https://en.wikipedia.org/wiki/Object_diagram)

i hope that we can discuss these object diagrams to see:

• if they represent the UML model correctly
• if they highlight any potential limitations in the model
• if they are a powerful communication tool to provide to the coverage teams;
  • If so, I'd like to get the UML details correct, then work on the commentary to help coverages folks understand the implications for 19123

[marqh]

1st example:
single location, based on a 4-tuple of (longitude, latitude, height, time)

Individual coordinate values from the tuple are referenced to a coordinate system axis based on position within the tuple

• is this correct?

[marqh]

2md example:
image, where the list of i coordinate values are in a separate list from the list of j coordinate values

How does the coordinate define which coordinate axis it is?
I have introduced 2 non-standard attributes, to try and address this (implying a missing piece in our model). Is there already functionality to do this that I am missing or mis-understanding?

This approach is not favoured, see comments below

[RogerLott]

Useful start to a conversation we need to deliver on in the very near future.

Example 1 is correct if the height is ellipsoidal height and part of a 3D geographic CRS. In application it is more likely that the height might be from a vertical CRS. In that case the compound CRS has three (ordered) components of GeodeticCRS, Vertical CRS and TemporalCRS. It might be better to show this because it is then easy to show that the vertical CRS may be replaced by a parametric CRS.

Eaample 2 is effectively creating a totally different model to that we have in 19111. I question whether a 2D CRS can be split into two 1D parts. 19111 does not allow it - it undermines its philosophy of fully and uniquely describing position. If you had two independent 1D CRSs they could be individually described (each with a datum and a CS) and then combined through the compound CRS construct.
I will comment further on this later - unable to do so at the moment.

[pebau]

Hi all, actually, the coverage data & service model has been designed in a way so as to minimize the interface between coverage "world" and other "worlds", such as CRSs. Trying to summarze (currently itting in the ESA Datacube workshop): - a coverage has exactly one CRS, containing all spatial, temporal, and other axes - a CRS _shall_ be identified by a URL - that URL _should_ resolve (could be the OGC resolver or any other), but this is not mandatory from the standards view - axes have a well-defined order. That order is listed in the coverage. In CIS 1.0, axisAbbrev was used, in CIS 1.1 axis names in the coverage can be chosen freely, matching with the CRS definition is by position in the axisLabels attribute Degrees of freedom: - coordinates can be any string, such as 42.3 or 42°15' or 2017-10-19 - no assumption is made about axis sequence _within_ concrete coordinates (that is clarified in one place in the coverage, see above) because each coordinate value is properly modeled as separate XML/JSON/RDF item (so we avoid the well-known WMS issue) Here is a concrete example (find more on http://schemas.opengis.net/cis/1.1/):         <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 10/18/2017 05:42 PM, marqh wrote: I have been investigating how coverages may use 19111 CRS instances. I believe there is a degree of expectation on the 19111 group to provide input to the 19123 editing team on this topic. I have prepared a set of object diagrams, based on the class diagrams in this repository. I will put these in individual comments, with a commentary alongside each one. These show how a set of objects, instances of the classes, may be used to define a specific scenario (https://en.wikipedia.org/wiki/Object_diagram) i hope that we can discuss these object diagrams to see: * if they represent the UML model correctly * if they highlight any potential limitations in the model * if they are a powerful communication tool to provide to the coverage teams; o If so, I'd like to get the UML details correct, then work on the commentary to help coverages folks understand the implications for 19123 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejpKDBl5OLR7Wu11HnQJubtnVq_WTks5sthxagaJpZM4P97LI>.

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

without being able to dive too deep into this due to my workshop involvement here: looks good. Note that we do not identify _coordinates_ by position but by axis name, see previous example.

…

-Peter

On 10/18/2017 05:45 PM, marqh wrote: 1st example: single location, based on a 4-tuple of (longitude, latitude, height, time) Individual coordinate values from the tuple are referenced to a coordinate system axis based on position within the tuple * is this correct? singlelocation <https://user-images.githubusercontent.com/1557321/31728212-2fc22bc0-b41b-11e7-80cb-e89c3bb9e4b0.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejoJjpg8Fswg1ekwYk4LttCE48dDmks5sth0ogaJpZM4P97LI>.

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

FWIW, here a slide I have done earlier, it might show our view on CRS use.

…

-Peter

On 10/19/2017 09:44 AM, RogerLott wrote: Useful start to a conversation we need to deliver on in the very near future. Example 1 is correct if the height is ellipsoidal height and part of a 3D geographic CRS. In application it is more likely that the height might be from a vertical CRS. In that case the compound CRS has three (ordered) components of GeodeticCRS, Vertical CRS and TemporalCRS. It might be better to show this because it is then easy to show that the vertical CRS may be replaced by a parametric CRS. Eaample 2 is effectively creating a totally different model to that we have in 19111. I question whether a 2D CRS can be split into two 1D parts. 19111 does not allow it - it undermines its philosophy of fully and uniquely describing position. If you had two /independent/ 1D CRSs they could be individually described (each with a datum and a CS) and then combined through the compound CRS construct. I will comment further on this later - unable to do so at the moment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejojlwrb1ktxt56QBIsM2XFT-Lupzks5stv3qgaJpZM4P97LI>.

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

corresponding example in coverages:         <GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">             <IndexAxis axisLabel="i" lowerBound="0" upperBound="2"/>             <IndexAxis axisLabel="j" lowerBound="0" upperBound="2"/>         </GeneralGrid>

…

-Peter

On 10/18/2017 05:50 PM, marqh wrote: 2md example: image, where the list of i coordinate values are in a separate list from the list of j coordinate values How does the coordinate define which coordinate axis it is? I have introduced 2 non-standard attributes, to try and address this (implying a missing piece in our model). Is there already functionality to do this that I am missing or mis-understanding? simpleimage <https://user-images.githubusercontent.com/1557321/31728527-120e5256-b41c-11e7-92f3-5a4b05ebab8a.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejpn5cWDjC-NIyQ29-jLi3k1AE_4Tks5sth5MgaJpZM4P97LI>.

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

[desruisseaux]

Thanks for those examples, I think it is helpful to have such use cases. In example 1, I wonder why coordinateDataType is set to integer since the axes are latitude, longitude and height in degrees and metres? Those coordinate tuples are conceptually real numbers, and whether a grid coverage or file format stores them as floating point numbers or integers should not be a concern for the CRS. Said otherwise, having a CoordinateSet with integer values and another CoordinateSet with floating-point values does not prevent them from being associated to the same CRS. I think that coordinateDataType should be set to integer only when using floating point numbers does not make sense. Maybe the intend was to use OrdinalCS in example 1 with i and j axes instead of longitude and latitude axes?

On example 2, if the sentence "the list of i coordinate values are in a separate list from the list of j coordinate values" means that i and j are stored separately on the storage device (file format, _etc.) but can be assembled as (i, j) tuples for the sake of coordinate operations, then I would said that this is not a concern for ISO 19111. More generally I think that whether the tuples are stored as IEEE 754 double-precision, IEEE 754 single-precision, 32 bits signed integer, 16 bits unsigned integers, little endian/big endian, i, j tuples together or in separated chunks, formatted as ISO dates or milliseconds since Unix epoch, etc. are not of concern for ISO 19111. It is rather the job of an data format driver (GeoTIFF driver, etc.) to convert the underlying data to numbers in the order defined by the CRS.

[pebau]

PS: forgot one requirement: - the coordinate value set of an axis shall be totally ordered (likely trivial, though); this we need to be able to do trimming. cheers, Peter

…

On 10/19/2017 10:21 AM, Peter Baumann wrote: Hi all, actually, the coverage data & service model has been designed in a way so as to minimize the interface between coverage "world" and other "worlds", such as CRSs. Trying to summarze (currently itting in the ESA Datacube workshop): - a coverage has exactly one CRS, containing all spatial, temporal, and other axes - a CRS _shall_ be identified by a URL - that URL _should_ resolve (could be the OGC resolver or any other), but this is not mandatory from the standards view - axes have a well-defined order. That order is listed in the coverage. In CIS 1.0, axisAbbrev was used, in CIS 1.1 axis names in the coverage can be chosen freely, matching with the CRS definition is by position in the axisLabels attribute Degrees of freedom: - coordinates can be any string, such as 42.3 or 42°15' or 2017-10-19 - no assumption is made about axis sequence _within_ concrete coordinates (that is clarified in one place in the coverage, see above) because each coordinate value is properly modeled as separate XML/JSON/RDF item (so we avoid the well-known WMS issue) Here is a concrete example (find more on http://schemas.opengis.net/cis/1.1/):         <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 10/18/2017 05:42 PM, marqh wrote: > > I have been investigating how coverages may use 19111 CRS instances. I > believe there is a degree of expectation on the 19111 group to provide input > to the 19123 editing team on this topic. > > I have prepared a set of object diagrams, based on the class diagrams in this > repository. I will put these in individual comments, with a commentary > alongside each one. > These show how a set of objects, instances of the classes, may be used to > define a specific scenario > (https://en.wikipedia.org/wiki/Object_diagram) > > i hope that we can discuss these object diagrams to see: > > * if they represent the UML model correctly > * if they highlight any potential limitations in the model > * if they are a powerful communication tool to provide to the coverage teams; > o If so, I'd like to get the UML details correct, then work on the > commentary to help coverages folks understand the implications for 19123 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#35>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AF0ejpKDBl5OLR7Wu11HnQJubtnVq_WTks5sthxagaJpZM4P97LI>. > -- Dr. Peter Baumann - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: ***@***.*** tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: ***@***.*** tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

-- Dr. Peter Baumann - 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 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)

[marqh]

@desruisseaux

In example 1, I wonder why coordinateDataType is set to integer since the axes are latitude, longitude and height in degrees and metres?

this is a mistake on my part, it was brought in by accident from a similar diagram. I have deleted this and updated the diagram, as I don't want to have this up for questions when it is just me making an editing error

i hope this is ok

[marqh]

@RogerLott

Example 2 is effectively creating a totally different model to that we have in 19111. I question whether a 2D CRS can be split into two 1D parts.

I understand you will post further on this when you are able to. I would like to pick up on this point and explore some language, perhaps this is splitting hairs, perhaps it is useful, I'm not sure.

I would like to say that this example is not separating out a 2D CRS. It is explicitly enabling two independent lists of coordinate values to reference different particular parts of a 2D CRS.

This coordinate value separation enables the product of the two coordinates to be defined and the structure of that definition, (the grid, if you like) to be constructed.

This is effectively a large list of coordinate tuples, but the definition ensures that a grid results, not an arbitrary collection of tuples.

One way to enable this to happen is to allow a CoordinateSet to be a 1D array of values and enable it to explicitly reference the axis name of the CoordinateAxis it is defined with respect to. Hence my suggestion of a new attribute cs_axis to enable this. This is not in our model at present.
https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Set%20and%20Metadata.png

@desruisseaux

On example 2, if the sentence "the list of i coordinate values are in a separate list from the list of j coordinate values" means that i and j are stored separately on the storage device (file format, _etc.) but can be assembled as (i, j) tuples for the sake of coordinate operations, then I would said that this is not a concern for ISO 19111.

The list of i and j coordinate values can indeed be assembled as (i, j) tuples, that is exactly the intent. This combination is a product, there is an (i, j) tuple for every (i, j) combination.

[desruisseaux]

Thanks for the fix. In example 1, unless I got the intend wrong, there is still the axis directions to edit. They are currently positive for each axis, but they should be north for latitude, east for longitude, up for height and future for the time axis.

On example 2, the two lists of independent coordinate values looks a lot like the netCDF Common Data Model (CDM). NetCDF files indeed have two arrays of values named "latitude" and "longitude", and the netCDF CDM represent them by a CoordinateAxis1D class (they also have a CoordinateAxis2D class, which looks quite surprising at first). But the CDM model is very different than ISO 19111 model. The CDM "CoordinateSystem" class is basically a merge of ISO 19111 CoordinateReferenceSystem, CoordinateSystem and OGC 01-004 GridGeometry types into a single class, with ReferenceFrame nowhere. The CDM "CoordinateAxis1D" and "CoordinateAxis2D" classes are basically merges of ISO 19111 CoordinateSystemAxis together with fragments of OGC 01-004 GridGeometry.gridToCRS (a property of type OGC 01-009 MathTransform). Given how different CDM and ISO 19111 models are, I would suggest to not take too much inspiration from CDM. I think that OGC 01-004 is a better model, where the relationship between the two lists and the CRS axis can be describes by the GridGeometry.gridToCRS property. For example for telling that the first list reference the second CRS axis and that the second list reference the first CRS axis, we can set GridGeometry.gridToCRS to the following affine transform:

0 1 0
1 0 0
0 0 1

Of course this would need more explanatory text, but this would be independent of ISO 19111 (GridGeometry is now superseded by work from the coverage group, but I have not seen yet a replacement as powerful and elegant in my opinion as OGC 01-004 GridGeometry was).

[pebau]

Martin-

On 10/20/2017 10:56 AM, Martin Desruisseaux wrote: Thanks for the fix. In example 1, unless I got the intend wrong, there is still the axis directions to edit. They are currently |positive| for each axis, but they should be |north| for latitude, |east| for longitude, |up| for height and |future| for the time axis. On example 2, the two lists of independent coordinate values looks a lot like the netCDF Common Data Model (CDM). NetCDF files indeed have two arrays of values named "latitude" and "longitude", and the netCDF CDM represent them by a CoordinateAxis1D <http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/javadoc/ucar/nc2/dataset/CoordinateAxis1D.html> class (they also have a CoordinateAxis2D <http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/javadoc/ucar/nc2/dataset/CoordinateAxis2D.html> class, which looks quite surprising at first). But the CDM model is very different than ISO 19111 model. The CDM "CoordinateSystem" class is basically a merge of ISO 19111 |CoordinateReferenceSystem|, |CoordinateSystem| and OGC 01-004 |GridGeometry| types into a single class, with |ReferenceFrame| nowhere. The CDM "CoordinateAxis1D" and "CoordinateAxis2D" classes are basically merges of ISO 19111 |CoordinateSystemAxis| together with fragments of OGC 01-004 |GridGeometry.gridToCRS| (a property of type OGC 01-009 |MathTransform|). Given how different CDM and ISO 19111 models are, I would suggest to not take too much inspiration from CDM. I think that OGC 01-004 is a better model, where the relationship between the two lists and the CRS axis can be describes by the |GridGeometry.gridToCRS| property. For example for telling that the first list reference the second CRS axis and that the second list reference the first CRS axis, we can set |GridGeometry.gridToCRS| to the following affine transform: |0 1 0 1 0 0 0 0 1 | Of course this would need more explanatory text, but this would be independent of ISO 19111 (|GridGeometry| is now superseded by work from the coverage group, but I have not seen yet a replacement as powerful and elegant in my opinion as OGC 01-004 |GridGeometry| was).

out of curiosity, can you explain this a little? Where do you see the advantages over the coverage approach? thanks, Peter

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejtdmFRKeeHkCLtOKmS24xokfZ_Zfks5suGA3gaJpZM4P97LI>.

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

[desruisseaux]

Hello Peter. OGC 01-004 GridGeometry was built on top of OGC 01-009 MathTransform. Since MathTransform has been omitted from ISO 19111, the ISO 19123 standard could not leverage it in the way OGC 01-004 did. A MathTransform was a mathematical transformation of coordinates between two spaces, not necessarily geospatial; OGC 01-009 explicitly said that it could also be a transformation between color spaces for example. The ISO 19111 CoordinateOperation type that we have today could be seen as a specialization of MathTransform when the source and target spaces are spatio-temporal (described by CoordinateReferenceSystem).

OGC 01-004 and 01-009 were designed in an age when web-related technologies (XML, etc.) were not as dominant as they became later. Consequently MathTransform was basically a pointer to a function (or an interface in COM, CORBA or Java); how the function is represented in XML was not a primary concern. They did defined a WKT representation, but it covered mostly affine transforms, map projections and Molodensky transformations. The key idea is that, as a pointer to a function, MathTransform could be anything, not necessarily representable in XML. We do not need an XML representation for everything. For example when reading a netCDF file with "longitude" and "latitude" variables as described by Mark in an above comment (where the grid cell coordinates are formed by the product set of those two variables), a MathTransform is built internally by the piece of software that read binary data in netCDF files. Whether a XML or WKT representation exists for that MathTransform is irrelevant; software developers in C/C++, Java, Python, etc. just get a pointer to a function. Interoperability is ensured by the netCDF binary encoding specification (OGC 10-92).

OGC 01-004 GridGeometry was made of the following properties:

• The number of cells along each dimensions. It was called GridRange in OGC 01-004, is now called GridEnvelope in ISO 19123, and is called shape in netCDF data model.
• The mathematical relationship from grid indices to the CRS (gridToCRS) as a MathTransform. This relationship is often affine, but not necessarily. In ISO 19123 RectifiedGrid (I will discuss ReferenceableGrid later) this is represented by the offset vectors and origin attributes, but those two attributes can represent only affine transforms. The OGC 01-004 MathTransform was more generic.
• gridToCRS relationship was fixed to cell center. If someone needed a cell corner, (s)he can simply pre-concatenate a (0.5, 0.5) translation before the gridToCRS transform.
• Geospatial Envelope can be computed from the above.

My feeling of discussions I have hear (please correct me if I'm wrong) is that part of the difficulty with ImageCRS came from attempts to apply it for describing the grid - which is not yet at this stage a geospatial object - in order to allow usage of a CoordinateOperation for describing the "grid to CRS" relationship. In OGC 01-004 this problem did not existed because the grid had no CRS, and the gridToCRS relationship described by MathTransform didn't needed any CRS. The grid exists in a mathematical space which is not geospatial. The "grid shape" (in netCDF terminology) has no geometric meaning. The grid gets a geometric shape only after transformation in a geospatial space as a result of the gridToCRS transform. In Southampton I have hear some OGC members saying that a next difficulty to solve was how to represent curved grids like the ones used in meteorological models. In OGC 01-004 there is no such thing as a "curved grid". We only have a grid with a non-affine gridToCRS, and the curved aspect is given by the later. We can not represent that in an ISO 19123 RectifiedGrid because it is restricted to affine transforms, but OGC 01-004 through its use of MathTransform had no such restriction.

In ISO 19123, non-affine gridToCRS relationship is rather specified by ReferenceableGrid. But it forces us to handle two types of coverages where OGC 01-004 had a unified model. Furthermore the relationship is defined by a way yet more opaque than MathTransform was (with coordTransform and invCoordTransform methods - in OGC 01-004 at least we could get the WKT for common cases).

MathTransform can also be used for representing the transfer function (ISO 19115 terminology) from pixel values to geophysics values (e.g. Sea Surface Temperature). The transfer function is often represented by a scale and offset attributes, but it is also sometime a logarithmic functions (e.g. images of chlorophyl-a concentrations). In this case, the destination space is the "sample dimensions" space instead than spatio-temporal dimensions.

[marqh]

I'd like to revisit @RogerLott 's comment:

Example 2 is effectively creating a totally different model to that we have in 19111. I question whether a 2D CRS can be split into two 1D parts. 19111 does not allow it - it undermines its philosophy of fully and uniquely describing position.

and reconsider the interface between 19111 and 19123.

I have been back through 19123:2007 and 19111:2007. I am concerned that interpretations of the way that 19123:2007 defines the interface to 19111:2007 is at the root of our problems and that Roger's comment highlights this.

The 19111 model starts with the CoordinateSet, an ordered collection of CoordinateTuple instances. https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Set%20and%20Metadata.png

This interface, via CoordinateMetadata, to a CRS is dependent on the ordering of the CoordinateTuple instances within the CoordinateSet. This collection of values into a tuple with explicit ordering is the core of the 19111 interface.

In 19123:2007 Figure 2 - CV_Coverage, there is an explicit reference, stating that 1 CV_Coverage references exactly one SC_CRS.

But CV_Coverage is not a CoordinateSet, it does not explicitly state that it contains an ordered collection of CoordinateTuples.

i think this is causing interpretation problems with the 19123:19111 interface

In 19123:2007 '5.1.2 Domain of a Coverage' states: A coverage domain is a set of geometric objects described in terms of direct positions. ... The direct positions are associated with a spatial or temporal coordinate reference system.

19123:2007 Figure 2 - CV_Coverage mandates that a CV_Coverage contains one or more CV_DomainObject instances.

I do not think that 19123:2007 is clear enough in defining how this interface should be implemented. Reading between the lines and applying the 19111 model I think that the 19123 model can be seen to be requiring that a CoordinateSet of CoordinateTuple instances is supplied, but this is not clearly mandated, in my view.

Applying this logic to my example 2 from above, I would reinterpret this and provide a derived CoordinateSet. The list of i values and j values are stored in separate arrays and used to index into array dimensions, as before. I believe this is consistent with the example provided here: #35 (comment)
Both of these seem like simple examples of the CV_DiscretePointCoverage, a very common case.

I have provided an extra object in my new example: it is a CoordinateSet, but it is derived from other values, in this case 2 1D arrays of coordinate tuple sub-sets. The CoordinateSet of CoordinateTuple instances is not stored directly, but it is fully accessible. I would not suggest that this is defined within 19111, this is an extension to work with the same interface design.

This new object contain sufficient information to provide a CoordianteSet of CoordinateTuple instances enabling it to reference the 19111 CRS effectively.

1. Does this reinterpretation better fit the 19111 model than my earlier example?
2. Does this provide a potential mechanism to improve the clarity of the interface from 19123 to 19111?
3. Does the example provided by @pebau in Providing Coverage Advice #35 (comment) already contain similar information, all be it encoded in a different form?