CRS support in NDG

Dimensions in CSML should always be described in terms of a Coordinate Reference System (CRS). A CRS must have well defined axis names, units and direction.

This is complicated in NDG as we probably have data in hundreds of different coordinate reference systems when you take into account different names and units. (This is becoming apparent as I try to make generic WMS capabilities documents for atmospheric model data...)

To provide some sort of formality in the way we handle CRSs I have written some code that is a dummy CRS catalogue that will store:

  1. the name of each known CRS
  2. the names of the axes
  3. the units of the axes
  4. the direction of the axes

(This is really just a stub for a service we need to implement at some point in the future.)

I had originally thought we could define a handful of fairly 'loose' coordinate reference systems eg x,y,height or x,y,pressure, time and use these. However the fact that a CRS must also contain units (and direction!) means that "x,y,height" with units "degrees_east, degrees_north, metres" is not the same crs as "x,y,height" with units "degrees_east, degrees_north, metres"!

So I think the number of CRSs we need is starting to look unmanageable at this stage.

I'm proposing that as well as defining some CRSs that DO match our underlying data we allow the use of 'pseudo' CRSs that aren't actually (very) well defined, and that take their definition from the underlying data format.

So in CSML a ndg 'pseudoCRS' would be encoded as something like this:

 <!GridSeriesDomain srsName="ndg:pseudoCRS" axisLabels="longitude latitude surface time" uomLabels="degrees_north, degrees_east, level,  days" gml:id="FgbMkeqw" dimension="4" srsDimension="4">

with the axis labels and units being encoded explicitly in the CSML.

As opposed to a well defined CRS, which can look up it's axes and units in the catalogue:

<!GridSeriesDomain srsName="ndg:crs:abc" dimension="4" srsDimension="4" gml:id="RJdq7slE">


  1. Does anyone have any strong objections to using these placeholder pseudoCRSs as a pragmatic solution in the case where the underlying CRS is not known to the catalogue? If so, please provide an alternative solution...
  2. Can data providers please send me (or document on the wiki) commonly used CRSs that they know they want to be in the catalogue. These must have axis names, and units. We at BADC have an ongoing project to try and capture these more formally, but this is just an attempt to get something semi-useful into the stub catalogue in the meantime.

Commonly Used CRSs:

Feel free to list your CRSs here with axis names, units and directions. I will then collate them later: