Skip to content
This repository has been archived by the owner on Jun 7, 2020. It is now read-only.

Providing Coverage Advice #35

Open
marqh opened this issue Oct 18, 2017 · 20 comments
Open

Providing Coverage Advice #35

marqh opened this issue Oct 18, 2017 · 20 comments

Comments

@marqh
Copy link
Member

marqh commented Oct 18, 2017

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
Copy link
Member Author

marqh commented Oct 18, 2017 •
edited
Loading

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

@marqh
Copy link
Member Author

marqh commented Oct 18, 2017 •
edited
Loading

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
Copy link

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
Copy link

pebau commented Oct 19, 2017 via email

@pebau
Copy link

pebau commented Oct 19, 2017 via email

@pebau
Copy link

pebau commented Oct 19, 2017 via email

@pebau
Copy link

pebau commented Oct 19, 2017 via email

@desruisseaux
Copy link

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
Copy link

pebau commented Oct 19, 2017 via email

@marqh
Copy link
Member Author

marqh commented Oct 19, 2017

@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
Copy link
Member Author

marqh commented Oct 19, 2017

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

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
Copy link

pebau commented Oct 20, 2017 via email

@desruisseaux
Copy link

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
Copy link
Member Author

marqh commented Oct 24, 2017 •
edited
Loading

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.

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 Providing Coverage Advice #35 (comment) already contain similar information, all be it encoded in a different form?

@desruisseaux
Copy link

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
Copy link
Member Author

marqh commented Oct 24, 2017 •
edited
Loading

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
Copy link

pebau commented Oct 24, 2017 via email

@pebau
Copy link

pebau commented Oct 24, 2017 via email

@marqh
Copy link
Member Author

marqh commented Nov 8, 2017

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

@marqh marqh mentioned this issue Dec 27, 2017
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@desruisseaux @marqh @pebau @RogerLott