Non-linear grids in coverage JSON

[allanfrankwork]

TL;DR summary: How can I tell clients about the projected CRS of my dataset and/or query data stored in a non-trivial CRS?

We are considering using EDR (https://docs.ogc.org/is/19-086r5/19-086r5.html) and CoverageJSON for a dataset with what I would call non-liniar grids - grids that do not line up in WGS 84 - last image on https://confluence.govcloud.dk/display/FDAPI/About+HARMONIE describes this.

Coordinates in the source .grib files are nice and liniar and use a projection/algorithm to rotate around a certain point to get WGS84 coordinates.

So question is how we can model this to make a service that makes sense to clients and aligns with EDR and Coverage JSON specs. I have found an old issue on this theme at https://github.com/covjson/specification/issues/32 but it was closed without solution.

Options that I can think of:

• Do nothing - client must project its query coordinates and project result coodinates back to WGS84 for example. Leave references section empty and client must hardcode.

• Keep source coordinates and in the references section using something like so:

  "coordinates": ["y","x"], "system": { "type": "ProjectedCRS", "id": "+proj=ob_tran +o_proj=longlat +o_lon_p=-0 +o_lat_p=40 +lon_0=26.5 +R=6367470 +no_defs +type=crs" } (id is the proj4 string - a custom non opengis.net url could also be used that has this information)

  this would allow use of coverageJSON grid to return data as normal, but harder for clients to find coordinates in WGS 84. Client must still project/convert the query coordinates.

  In addition a custom longitude/latitude "parameter" could be generated to have WGS84 coordinates as a parameter. As stated in above issue, this does not make sense for use with additional timesteps or z coordinates as information would repeat. But clients could get this parameter once to avoid doing projection on their own. Possibly allow client to somehow to query using WGS84 coordinates even though result is in a different CRS.

• Not to use grids and use a different coverage JSON structure - Trajectory? Collection of points? Both are kind of verbose and do not seem intended for this use.

• Resample grid to align with WGS84 (or any input CRS for that matter). This creates a new dataset so has its own set of problems.

Any other ideas?

Thanks.

[jonblower]

Hi @afasseco, thanks for a very good question. I think that your second option is the best, but at the moment, there is no standardised way in CoverageJSON to encode a custom CRS that does not have a URI. Ticket #26 has a bit more detail - it is possible that we may one day adopt CRSJSON (which is adapted from PROJJSON) but even then I am not sure whether it will cover the use cases of rotated pole coordinates.

Strictly speaking, a rotated-pole system is not a "projection". So perhaps the correct answer is to develop a "RotatedCRS" definition, in which you can insert the relevant parameters, perhaps using syntax adapted from the CF Conventions.

@chris-little do you know of any plans to support rotated-pole CRSs in CRSJSON or other OGC standards?

[chris-little]

@jonblower @afasseco There is a proposal, though progress has been slow, from @desruisseaux to register in the OGC infrastructure various rotated pole CRSs, as defined in the WMO. Manual on Codes. No. 306, volume 1.2, parts B and C.. The code is here .

The long term intent/goal is that WMO would expose machinable registers of their CRS definitions, perhaps is various formats such as WKT and ProjJSON (aka OGC CRSJSON). The intermediate goal is for OGC to host the registers, with references to WMO as the auth.oritative body. This should now be feasible, and the defintions could move from the MetOceanDWG repo to the now near-production OGC Naming Authority registers.

There is a similar approach currently for non-earthly, planetary CRSs.

[allanfrankwork]

Thanks very much for replies @jonblower and @chris-little - I learned a lot from those included links.

I understand that there is no standardised way to do this so I'm figuring out what would make most sense to clients and align best with any future developments in CoverageJSON and EDR specs.

In my example I have corrected type to be RotatedCRS as @jonblower pointed out.

Example:

"coordinates": ["y","x"],
"system": {
  "type": "RotatedCRS",
  "id": "native"
}

Have also changed id - I realise that this must also be the string that clients use when specifying CRS in request, so proj string is not a good fit. This requires good service documentation explaining clients what is meant by "native". (And possibly use the latitude/longitude layer mentioned earlier.)

Looking through the links @chris-little pointed out i'm guessing that using https://github.com/opengeospatial/MetOceanDWG/blob/main/MetOceanDWG%20Projects/Authority%20Codes%20for%20CRS/RotatedCS.xml I should be able to build a rotated GML definition with our parameters which could be hosted on opengis.net and use that as id. Though this would require rotated-CS to be available on opengis.net/epsg.

As @jonblower hinted looking through CRSJSON / PROJJSON these also do not seem to have a notion of Rotated pole system.

Thanks!

[desruisseaux]

The use of JSON versus GML versus WKT does not make real difference. It is a matter of defining what ISO 19111 calls "operation method", which is a process mostly independent of the encoding used for expressing the CRS. We can not add operation methods in opengis.net/epsg because that space should be only a mirror of what EPSG decides to publish. But we can add operation methods in opengis.net/ogc and indeed a definition for Pole Rotation has already been added under OGC:110 code:

http://www.opengis.net/def/method/OGC/0/110

But then, map projection libraries need to understand the parameters listed in above link. It requires (if not already done) updating the Java or C/C++ source code of the library. There is currently no OGC standard capable to encode the formulas of an operation method.

[desruisseaux]

Note: the above link to opengis.net does not fully resolve the issue described in the MetOcean wiki page. The GML currently only said:

<gml:formula>See netCDF-CF conventions, section "Rotated Pole".</gml:formula>

But that netCDF-CF section said nothing about the formula and the parameter values. We need a reference to something more detailed, like this page. But that page is only a wiki, it would need to be something more official.

[allanfrankwork]

That's interesting @desruisseaux - when I read that text earlier I was unsure of how the parameters would be included in that link.

With above example:

+proj=ob_tran +o_proj=longlat +o_lon_p=-0 +o_lat_p=40 +lon_0=26.5 +R=6367470 +no_defs +type=crs

I assume those parameters should somehow be encoded in the PoleLatitude/PoleLongitude/AxisRotation listed in http://www.opengis.net/def/method/OGC/0/110 (which says North pole rotation, but this can maybe also be used with a south pole rotation if arguments are converted?)

So since it looks like a URL something like http://www.opengis.net/def/method/OGC/0/110?PoleLatitude=40&PoleLongitude=26.5&AxisRotation=0 ?

[desruisseaux]

In the PROJ definition, the +o_proj=longlat part is equivalent to the "Operation method" part in ISO 19111. The only legal argument values are the ones that are hard-coded in the library.

I'm not aware of a URL syntax where we specify the parameters of an operation method. Such URL would not be sufficient anyway because we also need to specify the reference frame (datum), coordinate system type, axis order, axis directions, units of measurement, etc. The usual approach is to create another definition, this time in the http://www.opengis.net/def/crs space, with a GML for the CRS using the operation method defined elsewhere. In other words the steps are:

• First define an operation method in e.g. http://www.opengis.net/def/method space.
• Then define an arbitrary number of CRS in e.g. http://www.opengis.net/def/crs space that reference above operation method.

I would recommend to not use PROJ 4 syntax as a source of inspiration for URL or any other design. The PROJ 4 syntax as many problems and is insufficient for unambiguous definition of CRS (it lacks all the stuff listed above about what would be lacking in an URL). I believe that PROJ 4 syntax is still supported in PROJ 6+ for compatibility reason, but that users are encouraged to use WKT 2 instead.

[chris-little]

@desruisseaux @afasseco @jonblower Another use for the RotatedPole, and also the 'stretched' grid, type of CRSs, that have been defined in the meteorological domain, is to use for 'space weather'. The poles of interest are not the geographical poles but the magentic poles, which will also need an 'epoch' as they are moving quite rapidly at present. and the 'stretching' may be not a simple mathematical function.

So we are having a convergence of requirements for registers and authoritative definitions of a wider range of CRSs than originally envisaged by OGC and ISO.

@ghobona For your information - OGC may need to be the host of these register entries until the authoritative bodies get their production technology acts together.

[chris-little]

Two approaches needed: Tactical: supply guidance and best practice to allow users to construct their own CRSs. Strategic: Ensure definitions of specialised CRSs are in machinable authoritative registers, possibly initially hosted at OGC, and executable code exposed so users can easily use them.

[jonblower]

Thanks all, this has been a useful discussion. @afasseco, I guess you are still looking for a way to encode a rotated-pole CRS in CoverageJSON. I don't think there is a "proper" way to do this yet. The alternatives seem to be:

Option 1. Use the existing structure, but with custom values for type and id, e.g.:

"system": {
  "type": "RotatedCRS",
  "id": "http://www.opengis.net/def/method/OGC/0/110?PoleLatitude=40&PoleLongitude=26.5&AxisRotation=0"
}

I would not suggest such a structure myself, for the reason @desruisseaux points out above

Option 2. Use a different ad-hoc JSON object structure, in which the parameters are encoded:

"system": {
  "type": "RotatedCRS",
  "parameters": {
    "north_pole_longitude": 26.5,
    "north_pole_latitude": 40.0,
    "axis_rotation": 0
  }
}

This gives the same amount of information as the corresponding structure in CF, but as @desruisseaux points out, we don't have information on the datum etc.

Note that an earlier draft of the CoverageJSON spec (e.g. here) allowed for "inline" CRSs, but this was removed as it was not properly specified.

Option 3. Wait for CRSJSON, which might also involve waiting for this CRS type to be officially registered with OGC.

Personally, I would suggest the second option, and if this is preferred, we could even include this in future versions of CoverageJSON, and deprecate when/if CRSJSON solves this.

A final note - I think we will always need the capability to encode the rotated-pole parameters in the CovJSON. In some cases we might be able to use the URI of a complete CRS definition, but I'm not aware there are widely-used common instances. This CRS comes from the modelling community, and different models will need different parameters.

[allanfrankwork]

I agree - thanks everybody for good discussion.

I'm using CoverageJSON as output format for an OGC-EDR service, so I think I need some kind of crs id that the client can use to specify it in the request (...&crs=crs-id) and be present in meta-data for the queries. And since it cannot be done in a "proper" way I'll try to include as much information as possible to the clients so that they will not think its crs84 coordinates and find information on the rotated coordinates.

Thanks for following up @jonblower, this issue can be closed.

[jonblower]

OK, thanks, I'll close this! One final comment is that a rotated-pole CRS is quite a specialist one that will not be widely understood by users or client libraries. It may be worth considering transforming to another CRS on the server side, but maybe that doesn't fit your use case.