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