The Web Map Service (WMS) specification of the Open Geospatial Consortium (OGC) leaves to the service implementor the choice of which CRS definitions to support. These pre-defined CRS definitions are what enable clients to request maps in a projection of their choice. It is therefore up to this MetOcean community to decide how to leverage the WMS system to communicate unambiguously the CRS definitions offered by MetOcean WMS servers and used by WMS clients.

This page explains the need that this MetOcean community decide on its approach towards the definition of the needed CRS definitions for its use of WMS services. It is hoped that the page can be extended by all participants to define the CRS definitions which are needed. With this definition of needs, it will then be possible for this MetOcean community either to develop change requests to the WMS standard itself or to define the CRS system used by in the MetOcean profile.

Projection support in the WMS standard

The WMS standard defines only a limited number of CRS definitions which could be used by server implementations but the standard also refers to the EPSG database for a source of more CRS definitions. These CRS definitions are communicated through an identifier string concatinating an authority code, a colon marker (":"), and a numeric code for the CRS of choice, such as "CRS:1". For example, a client could make a getMap request including the CRS as: "...&CRS=EPSG:3995...".

The standard also defines five CRS definitions, all in the authority called "AUTO" (confusingly sometimes "AUTO2"), which can be parametrized with various values so that the identifier string concatenates an authority code, a colon marker, a numberic code for the CRS, and optionally any number of parameters separated using a comma marker (",") and defined with a parameter name, an equal sign separator ("="), and a parameter value. For example, a client could make a getMap request including the CRS as: "...&CRS=AUTO2:42003,latitude_of_origin=0,central_meridian=120...".

Current implementations of WMS often support all three of the CRS definition authorities mentioned in the WMS spec:

• the "CRS" authority supplied by CRS defintions given in the standard document (see WMS 1.3 Annex B),
• the "EPSG" authority supplied by CRS definitions extracted from the EPSG database,
• and the "AUTO" (or "AUTO2") authority supplied by CRS definitions given in the standard document (see WMS 1.3 Annex B).

These CRS definitions do not fully meet the needs of the MetOcean community. For example, the projection which matches the bird's eye view of geostationay weather satellites does not have any pre-existing CRS defintion in the current WMS system. As a second example, WMS does not yet provide a way to specify, in Polar Stereographic projections, a longitude parameter so that clients could control the rotation of the map. Furthermore, the CRS definitions in these three authorities provide very limited support for the common global projections: the standard declares only ten CRS definitions and the EPSG database arose as a way to share accurate, empirically validated, mathematical transformation parameters rather than as a way to share CRS definitions.

The MetOcean community is therefore left to define new CRS definitions to meet its own needs, possibly with a parametrization system for those CRS defintions which could be further parametrized.

Needed Spatial CRSs

The CRS definitions required by the MetOcean community seems to be relatively limited. A list of CRSs used within the Met community was obtained from the MetQuestionnaireSynthesis, which only revealed a small number of CRS definitions in use. Several of these exist within the EPSG database, while others are defined in open source software such as Proj4, Geotools or Geotoolkit.

We need to identify the projections useful for our community.

Met Ocean users are welcome to complete this list

Needed CRS codes which are already defined:

EPSG code	CRS type	Comment
EPSG:4326	Geographic	Using a WGS84 ellipsoid, results in an informal Plate-Carre map
EPSG:3395	Mercator	Using a WGS84 ellipsoid
EPSG:3785	Pseudo-Mercator	Using a sphere, the Google Maps (and others) projection
EPSG:32661	Polar Sterographic	Using a WGS84 ellipsoid, Arctic (north)
EPSG:32761	Polar Sterographic	Using a WGS84 ellipsoid, Antarctic (south)
EPSG:32{6-7}[01-60]	Universal Transverse Mercator	UTM, using a WGS84 ellipsoid, North (6), or South(7), zone 1 to 60
EPSG:31467	Transverse Mercator	DHDN / Gauss-Kruger zone 3
EPSG:900913	Pseudo-Mercator	Using a sphere, deprecated for EPSG:3785
EPSG:3111	Lambert Conic Conformal (2SP)	GDA94 / Vicgrid94
EPSG:3112	Lambert Conic Conformal (2SP)	GDA94 / Geoscience Australia Lambert
EPSG:3308	Lambert Conic Conformal (2SP)	GDA94 / NSW Lambert
EPSG:42304	Lambert Conformal Conic	NAD83 / NRCan LCC Canada
EPSG:23031	Transverse Mercator	ED50 / UTM zone 31N
EPSG:54004	?	?ESRI:54004 "World Mercator"?
EPSG:28992	Oblique Stereographic	Amersfoort / RD New
EPSG:23029	Transverse Mercator	ED50 / UTM zone 29N
EPSG:283[48-58]	Transverse Mercator	GDA94 / MGA zone 48-53
EPSG:9804	World Mercator	?an operation method?

EPSG code	Type	Comment
EPSG:4202	GeodeticCRS	GDA94 on Australian Geodetic Datum 1966
EPSG:4283	GeodeticCRS	GDA94 on Geocentric Datum of Australia 1994
EPSG:9804	Method	Mercator (variant A)
EPSG:9805	Method	Mercator (variant B)

Other needed CRS definitions:

(Note these could be added to the EPSG database or defined by the OGC as HTTP URIs; they should also be added to open source software packages.)

• orthographic Not confirmed after request to contributor
• Geos (for example) This projection is defined in WMO doc : LRIT/HRIT Global Specification

The ellipsoid used by this projection is specific. Based on an information from Eumetsat of Mid December 2010, there are no current plans to change it towards WGS84

• parametric CRS
• PROJ4:"+proj=stere +lat_0=90 +lat_ts=60 +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378273 +b=6356889.449 +units=m +no_defs",
• PROJ4:+proj=stere +lat_0=90 +lat_ts=60 +lon_0=10 +k=1 +x_0=0 +y_0=0 +a=6378273 +b=6356889.449 +units=m +no_defs",
• PROJ4:+proj=stere +lat_0=90 +lat_ts=60 +lon_0=20 +k=1 +x_0=0 +y_0=0 +a=6378273 +b=6356889.449 +units=m +no_defs
• Requirement of Polar Stereographic projection with arbitrary base meridian
• ...

Known issues:

• It's unclear how to find a proper CRS (for example EPSG) for projections which are used for years by Met services (for example smaller countries in Europe use quite often Lamber Conformal projection, which doesn't have any clear EPSG equivalent)
• EPSG has different kinds of objects referenced by one number. The Object may be a Map Projection , a Datum, an area or a Method. E.g. EPSG:3111

Possible solutions:

• AUTO2: CRS namespace - standard, but only very limited solution, could solve Polar Stereographic projection?
• implementation specific PROJ4: CRS namespace - not standard!
• MET: CRS namespace?

Needed Nongeospatial CRSs

There are special kind of meteorological products which are non-geospatial:

• Thermodiagrams (vertical atmosphere sounding profiles, for example)
• Time cross sections (for example)
• Horizontal (space) cross sections (for example)

WMS specification mentions CRS:1, which provides a pixel coordinate system, this could be used for any non-goespatial products.

Arguably, these non-geospatial products do not require special CRSs because the two concepts could be considered incompatible. In the above examples, the traditional concept of a CRS is just not applicable. One could argue that using an OGC service (such as WMS, WFS, WCS) to serve these products is inappropriate. Returning a cross section as a Feature is fine, but requesting that cross section would only require a CRS to specify the horizontal space (if appropriate, for example a horizontal cross section in a WMS GetFeatureInfo). Cross sections in TIME and ELEVATION should be specified in those dimensions. Inventing special CRSs for particular meteorological products that are not geospatial in nature seems like a bad idea.

Problems already identified with CRSs

Some servers ignore the CRSs requirement into the request.

The png provided by the server doesn't bring georeferencement so it not possible to check that the WMS provided is compliant with the requested CRS

Resources

• WMO

This document provides the coding facilities in GRIB2 to describe fully the projections, shape of the earth... available to define fully these attributes of the numerical model outputs.

• ISO : "The CRS should be defined in terms of ISO 19111:2007 which supports compound spatio-temporal CRS. And note we developed ISO 19111-2 specifically for the case of non-length based 'parametric CRS' used by met and other communities; however it does need to be populated" Andrew Woolf
• EPSG
• Euref
• Information and Service System for European Coordinate Reference Systems)
• Spatial Reference : Website aiming at assisting others in their understanding, recording, and usage of spatial reference systems