CRS Specification

From Earth Science Information Partners (ESIP)
Revision as of 03:10, August 6, 2012 by Martin Schultz (MartinSchultz) (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Email exchange with EPSG on proper definition of CRS for atmospheric model data

sent by Roger Lott (Chairman, OGP Geodesy Subcommittee), on 13 July 2012:

Dear Dr Schultz,

Your message has been passed on to me to answer.

Firstly, both urn:ogc:def:crs:OGC:2:84 and urn:ogc:def:crs:EPSG::4326 represent WGS 84, the coordinate reference system used by the US GPS satellite navigation system. The difference between them is that urn:ogc:def:crs:OGC:2:84 has coordinate order longitude, latitude whilst urn:ogc:def:crs:EPSG::4326 has coordinate order latitude, longitude. The OGP strategy is to populate ellipsoidal coordinate reference systems only in the order latitude, longitude. We do this for two reasons. Firstly several communities involved with safety of live issues, such as aviation and maritime, conventionally have always used this coordinate order. In emergency situations it can be critical that coordinates are presented as users expect, because in a stressful situation they may not have the opportunity to consider the detail of the coordinate values. Secondly, we follow ISO 6709 – Representation of geographic point position, which explicitly mandates coordinate order be latitude,longitude.

EPSG crs 4047.png

You should not be using WGS 84 if you are working with spherical coordinates. By definition, WGS 84 is ellipsoidal, so in suggesting that the values are WGS 84 implies that the model of the Earth is an ellipsoid. Ellipsoidal and spherical coordinates can differ by up to 800 metres. The nearest entry we have in the EPSG Dataset to match your requirements is urn:ogc:def:crs:EPSG::4047. I attach the description for this data (see image). Note (a) that if you are using a sphere with a radius different from 6371007 metres then you should not use this, and (b) this also is for coordinates in the order latitude, longitude and if you are using a different order again you should not use this.

Computations using an ellipsoid are more complex than those using a sphere, but with the power of modern computers they are quite easily handled. There are very few applications that actually require a sphere to be used, and unless you are in the most unlikely position of having one of them my recommendation to you is that you stop using a sphere and start using WGS 84 and its ellipsoid.

Two further comments I would make with regard to codes. Firstly, both urn:ogc:def:crs:OGC:2:84 and urn:ogc:def:crs:EPSG::4326 represent WGS 84 geographical 2D. If you are describing a WGS 84 ellipsoidal 3D system with coordinates of (in order) latitude, longitude and height above the ellipsoid in metres, then urn:ogc:def:crs:EPSG::4979 should be used. Secondly, if you have a 3-dimensional coordinate reference system where the third dimension is a parameter, say ‘pressure’, then you should be using a compound coordinate reference system comprising a geographic 2D (such as thoe discussed above) + a parametric coordinate reference system. There are no codes for such systems in OGC or EPSG. Parametric coordinate reference systems can be handled in our data model but despite this they are out of the scope of the Dataset content.

With regard to a search on “world”, we have two area descriptions in the EPSG dataset, one limited to the single word “World” and the other a text string beginning “World: …” followed by a list of country names. CRS urn:ogc:def:crs:EPSG::4326 is associated with the latter. In our online registry at www.epsg-registry searching automatically inserts wildcards both before and after the user string, so “world” is searched for as “*world*”. So a search on “world” [not case sensitive] would have found (amongst others) both urn:ogc:def:crs:EPSG::4326 and urn:ogc:def:crs:EPSG::4979. But in our downloadable Access database and SQL scripts the search syntax will need to be more specific, with any wild cards inserted into the query. So a query using “world*” would be necessary to have urn:ogc:def:crs:EPSG::4326 returned.

And lastly, a word on terminology. ISO 19111 distinguishes between a coordinate system (CS) and a coordinate reference system (CRS). A CRS comprises of a CS attached to an object (usually the earth) through a datum. The corollary is that a coordinate system is an abstract concept with no defined place. In your message to us you used “coordinate system” but were really writing about coordinate reference systems.

I trust that this answers your questions.

Regards,

Roger Lott Chairman, OGP Geodesy Subcommittee




From: Schultz, Martin Sent: 12 July 2012 08:53 To: Kryla-Straszewska, Lucyna Subject: Selection of proper EPSG coordinates for atmospheric model data

Dear Lucyna Kryla-Straszewska,

I am working on software systems and metadata definitions to set-up interoperable web services for atmospheric model data. One area that has caused considerable confusion in our community is the choice of the appropriate coordinate reference system to enter in our metadata records. Historically, people have mostly used crs="urn:ogc:def:crs:OGC:2:84" and referenced this to “WGS84”. More recently, I also came across “urn:ogc:def:crs:EPSG::4326”. When I searched the EPSG registry, I came up with a list of ~20 valid definitions for coordinate systems covering the area “World”. However, EPSG::4326 is not found among these. On the other hand, if I look for 4326 as a code, I obtain a valid metadata record covering the area “World”.

Basically, the coordinates we are using, are simple lat/lon with a spherical earth (no flattening). I would be very grateful if you could advise me which coordinate system(s) would be most appropriate to describe this.

Thank you very much in advance and kind regards,

Martin Schultz


PD Dr. Martin G. Schultz IEK-8, Forschungszentrum Jülich D-52425 Jülich Ph: +49 2461 61 2831



Addendum: from CF mailing list (2012 07 31):

crs:epsg_code = 4326 ; //this would be the 99% case. This is how google openlayers, wms, google, bing and others handle the tricky subject of geodesy metadata. [Paul Kennedy]