search

ISO-TC211 / ISO19111

Revision of ISO19111 - Spatial referencing by coordinates.
2 stars 0 forks source link

Providing Coverage Advice #35

Open marqh opened 6 years ago

marqh commented 6 years ago

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:

marqh commented 6 years ago

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

singlelocation

marqh commented 6 years ago

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

This approach is not favoured, see comments below

RogerLott commented 6 years ago

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 commented 6 years ago

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

Degrees of freedom:

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">                   0                 100                                         2015-12-01                 2015-12-02                         <GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index4D" axisLabels="i j k l">                                                                                    

...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 https://github.com/ISO-TC211/ISO19111/issues/35, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejpKDBl5OLR7Wu11HnQJubtnVq_WTks5sthxagaJpZM4P97LI.

-- Dr. Peter Baumann

pebau commented 6 years ago

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 https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-337635757, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejoJjpg8Fswg1ekwYk4LttCE48dDmks5sth0ogaJpZM4P97LI.

-- Dr. Peter Baumann

pebau commented 6 years ago

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

  1. 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 https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-337826406, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejojlwrb1ktxt56QBIsM2XFT-Lupzks5stv3qgaJpZM4P97LI.

-- Dr. Peter Baumann

pebau commented 6 years ago

corresponding example in coverages:

        <GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">                                

-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 https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-337637332, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejpn5cWDjC-NIyQ29-jLi3k1AE_4Tks5sth5MgaJpZM4P97LI.

-- Dr. Peter Baumann

desruisseaux commented 6 years ago

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 commented 6 years ago

PS: forgot one requirement:

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">                   0                 100                                         2015-12-01                 2015-12-02                         <GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index4D" axisLabels="i j k l">                                                                                    

...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 https://github.com/ISO-TC211/ISO19111/issues/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."

-- Dr. Peter Baumann

marqh commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-338148068, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejtdmFRKeeHkCLtOKmS24xokfZ_Zfks5suGA3gaJpZM4P97LI.

-- Dr. Peter Baumann

desruisseaux commented 6 years ago

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:

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 commented 6 years ago

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: https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-337835182 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.

tuplesimpleimage

  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 https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-337835182 already contain similar information, all be it encoded in a different form?
desruisseaux commented 6 years ago

I think that this figure works and stay in spirit of ISO 19111 (the coordinate system is not splitted in 1D components). But I wonder why DerivedCoordinateSet does not extends CoordinateSet in this use case?

One thing I would like to clarify: for me, CoordinateSet having a coordinateTuple attribute does not mean that the coverage or file format must contains internally a list of DirectPosition. It only means that the coverage must be able to generate that list if we ask it. In the two-dimensional grid coverage case, this list is generated by the product set of i and j values. But we can see that (at least from ISO 19111 perspective) as implementation details. So the DerivedCoordinateSet example make more explicit the details of how the coordinate tuples are generated, but it does not impact ISO 19111 model (however I agree that this it would be a nice example to put in annex for explaining how the relationship with ISO 19123 is done). Do I'm understanding right?

marqh commented 6 years ago

But I wonder why DerivedCoordinateSet does not extends CoordinateSet in this use case?

No reason, i suspect that this would be a good way to do it. (diagram updated)

CoordinateSet having a coordinateTuple attribute does not mean that the coverage or file format must contains internally a list of DirectPosition. It only means that the coverage must be able to generate that list if we ask it.

I agree

pebau commented 6 years ago

(cc'ing Doug so that he sees work is going on)

thanks a lot, Martin, good to learn about this history and also the approaches behind.

In fact, ISO 19123 as it stands might say too much about CRSs where it actually only should say what a grid is (reminds me of WCS 1.1.2: from the 136 pages there are 65 pages on CRSs, some text which is understood by maybe 5 people, and I am not one of them). But more importantly: externally referenced standards may have changed as well, so I am beginning to understand that these should undergo scrutiny as well. Any help is much appreciated.

I am still very much into separation of concerns: 19123 should define grids, but not make any assumption about CRSs, but just consume 19111. If that means weeding out from 19123, so be it - I am very open to collaborate.

cheers,

Peter

PS: I am more than happy about your "pixel in corner" solution of concatenating a translation. Actually, I was hoping for a general concept of how to obtain a pixel value from the measurement - I am no friend of enumeration values / code lists, they just categorize, but do not explain.

The concatenation you describe can be done perfectly with the current coverage concept - all we need is a crs-concat operation in the CRS URL.

On 10/21/2017 01:06 AM, Martin Desruisseaux wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-338341998, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejulb4BnijQzUu84eYHLGriQu3zn0ks5suSdjgaJpZM4P97LI.

-- Dr. Peter Baumann

pebau commented 6 years ago

On 10/24/2017 01:12 PM, Martin Desruisseaux wrote:

I think that this figure works and stay in spirit of ISO 19111 (the coordinate system is not splitted in 1D components). But I wonder why |DerivedCoordinateSet| does not extends |CoordinateSet| in this use case?

One thing I would like to clarify: for me, |CoordinateSet| having a |coordinateTuple| attribute does not mean that the coverage or file format must contains internally a list of |DirectPosition|. It only means that the coverage must be able to generate that list if we ask it.

indeed, this is exactly the transformation case, currently represented by SensorModel: coordinates have to be computed by interpreting the model data (which are not the direct position coordinates themselves). -Peter

In the two-dimensional grid coverage case, this list is generated by the product set of /i/ and /j/ values. But we can see that (at least from ISO 19111 perspective) as implementation details. So the |DerivedCoordinateSet| example make more explicit the details of how the coordinate tuples are generated, but it does not impact ISO 19111 model (however I agree that this it would be a nice example to put in annex for explaining how the relationship with ISO 19123 is done). Do I'm understanding right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/ISO19111/issues/35#issuecomment-338955997, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejpxWYtTfj0QvNCZ1x9Y02HoQEE1jks5svcYGgaJpZM4P97LI.

-- Dr. Peter Baumann

marqh commented 6 years ago

I have prepared some follow on examples, to help with these discussions. these should all use the 'DerivedCoordinateSet' approach already discussed. I aim to be consistent, all comments and queries are encouraged. In essence: are these examples valid interpretations of ISO19111?

Simple Image

tuplesimpleimage

Simple Image with stepwise i and j coordinate values

simpleimagestep

XY Z T using separate CoordinateTuple and CoordinateReferenceSystem Instances

geodeticdomainxy_z

XYZ T using separate CoordinateTuple and CoordinateReferenceSystem Instances

geodeticdomainxyz

XYZT CompoundCRS

geodeticdomainxyzt