Change "components" to "coordinates"?

[jonblower]

I think one of the hardest things to explain about CovJSON is the concept of "components", which link axis values to reference systems. I wonder if using the word "coordinates" instead might help.

For example, "This domain is defined using x, y and t coordinates. X and y coordinates are referenced using one reference system, while t coordinates are referenced using another. There is one axis for each kind of coordinate".

This feels more natural than "components". One problem is that some systems use "coordinates" for coordinate values, not identifiers.

This would make the JSON look like this:

"domain" : {
    "type": "Domain",
    "domainType": "Grid",
    "axes": {
      "x": { "start": -179.5, "stop": 179.5, "num": 360 },
      "y": { "start": -89.5, "stop": 89.5, "num": 180 },
      "t": { "values": ["2013-01-13T00:00:00Z"] }
    },
    "referencing": [{
      "coordinates": ["x","y"],
      "system": {
        "type": "GeodeticCRS",
        "id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"        
      }
    }, {
      "coordinates": ["t"],
      "system": {
        "type": "TemporalRS",
        "calendar": "Gregorian"
      }
    }]
}

[letmaik]

How would that look like for composite axes where you use the "coordinates" field both in the axis object and the referencing?

[jonblower]

I may be missing the point of your question but I think it would look fine. It actually makes more sense to me than "components":

{
  "dataType": "tuple",
  "coordinates": ["t","x","y"],  
  "values": [
    ["2008-01-01T04:00:00Z",1,20],
    ["2008-01-01T04:30:00Z",2,21]
  ]
}

... then ...

"referencing": [{
      "coordinates": ["x","y"],
      "system": {
        "type": "GeodeticCRS",
        "id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"        
      }
    }, {
      "coordinates": ["t"],
      "system": {
        "type": "TemporalRS",
        "calendar": "Gregorian"
      }
    }]

Glancing at the spec, I think if we replaced "components" with "coordinates" and made sure to distinguish between coordinate identifiers ("x", "y" etc) and coordinate values it would be fine.

[letmaik]

OK, how would you rephrase this spec part:

"CIS enforces exactly one coordinate reference system (CRS) per coverage, CoverageJSON allows CRSs to be associated with a given combination of components (TODO introduce components before)."

[jonblower]

I think the change actually makes this sentence in particular much better:   “CIS enforces exactly one coordinate reference system (CRS) per coverage, CoverageJSON allows multiple CRSs, each associated with a given combination of coordinates”

[letmaik]

OK, final question. What about things that aren't technically coordinates like IDs, as in identifier-based reference systems. And for that matter, time strings. I guess what I'm asking for is the definition of "coordinates" that we use.

[jonblower]

I don't think we should regard "coordinates" just as numeric values. It's certainly OK to refer to a time string as a "coordinate" - I think most people would be happy with that. For identifiers it's a bit more unusual, but no more unusual than "component" (which we really just made up). Identifiers aren't spatiotemporal coordinates, but serve a similar purpose, as markers in a particular dimension to distinguish things.

I'm struggling to find a form of words that defines "coordinate" adequately in this sense without getting recursive, or too confusing. I'm not sure we really need a formal definition - to me the term feels fairly natural in this context and matches the narrative description of the domain, as in my original post in this thread.

Here's a domain that might be used for a timeseries of temperature measurements per country (where the country is given by an identifier):

"domain" : {
    "type": "Domain",
    "axes": {
      "t": { "values" : ["2013-01-13T00:00:00Z", ... ] }
      "country" : { "values" : ["fr", "gb", "de", "it" ... ] }
    },
    "referencing": [{
      "coordinates": ["t"],
      "system": {
        "type": "TemporalRS", 
        ...
       }
      },{
      "coordinates": ["country"],
      "system" : {
        "type": "IdentifierRS",
       ...
      }
    }]
}

"coordinates": ["country"] maybe looks a little weird but I think in the context it's fairly clear what it means. IdentifierRSs are likely to be significantly rarer that spatiotemporal RSs anyway.

[letmaik]

(walking through some more spec stuff, just to be sure)

In 6.1.1 we have:

The value of "dataType" determines the structure of an axis value and its components that are made available for referencing. The values of "dataType" defined in this specification are "primitive", "tuple", and "polygon". Custom values MAY be used as detailed in the “Extensions” section. For "primitive", there is a single component and each axis value MUST be a number or string. For "tuple", each axis value MUST be an array of fixed size of primitive values in a defined order, where the tuple size corresponds to the number of components. For "polygon", each axis value MUST be a GeoJSON Polygon coordinate array, where each of the coordinate components (e.g. the x coordinates) form a component in the order they appear.

and

The value of "components" is a non-empty array of component identifiers corresponding to the order of the components defined by "dataType".

and

A component identifier SHALL NOT be defined more than once in all axis objects of a domain object.

In 6.1.2 we have:

A reference system connection object MUST have a member "components" which has as value an array of component identifiers that are referenced in this object. Depending on the type of referencing, the ordering of the identifiers MAY be relevant, e.g. for 2D/3D coordinate reference systems.

Can you translate these to "coordinates"? Especially in the last one, it seems that omitting "identifiers" is weird, so would that be "coordinate identifiers"?

[jonblower]

Yes, I think the last one would be fine with "coordinate identifiers". I might have a go at updating the spec test in a branch then submit a pull request, if that's OK? At the same time I'll give it a proper read-through and see if anything else can be clarified.

[letmaik]

Yes, a branch is fine.

[jonblower]

OK I've issued a PR