Hi, The EPSG codes are assigned by the OGP Geodesy Subcommittee, because the codes are and should be globally unique. Here is how to make a request (from EPSG guidelines):
5.2 How to make a request to add to or amend EPSG Dataset content Suggestions for improvements or additions to dataset content are accepted from any interested party. They should be made by electronic submission of the change request form which can be found by following the links to the geodetic subcommittee at the foot of the OGP Surveying and Positioning Committee web page www.epsg.org or at the foot of the geodetic dataset page www.epsg.org/geodetic.html. Change requests should clearly state what is being proposed. If the change is to existing dataset content then the entity type and code for the entity in question must be stated, preferably along with its name. If the request is to add new data then as a minimum the information tabulated in annex A of this document must be given. This minimum information may be included directly in the change request message or may be given indirectly by providing the URL for a publicly-available web site which contains the information. Requests received will be acknowledged by the OGP Geodetic Subcommittee, normally with one working week of receipt. If they are within scope they will be allocated a change request number and then reviewed by the Subcommittee. The Subcommittee may require the proposer to provide supplementary information before reaching a decision. Changes that are accepted are first made in an unpublished copy of the dataset and are put through a quality control check. Correspondents may be asked to comment on draft entries. The Subcommittee aims to process all requests within one release cycle of the dataset. Correspondents will be advised the decision reached as soon as it has been made. Where new data is added, the code(s) for this are made public only at the time of the next dataset release. For internal use (e.g. your company) you can define your own codes, outside the EPSG codes range. Regards, Zamfir Pop -----Original Message----- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of TOYODA Eizi Sent: Wednesday, October 05, 2011 9:16 AM To: Kennedy, Paul; Patrick Sunter; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Question on WKT representation of CRS (Bentley,Philip) > (Kennedy, Paul) Dears, Is it difficult to register a new EPSG code? I'm curious since I haven't tried, but they seem trying to be open to new proposal. Best Regards, -- Eizi TOYODA twitter.com/e_toyoda | toyoda.e...@gmail.com ----- Original Message ----- From: "Kennedy, Paul" <p.kenn...@fugro.com.au> To: "Patrick Sunter" <patdeve...@gmail.com>; <cf-metadata@cgd.ucar.edu> Sent: Wednesday, October 05, 2011 5:56 PM Subject: Re: [CF-metadata] Question on WKT representation of CRS (Bentley,Philip) > (Kennedy, Paul) Hi Patrick, I fully agree. There are a few instances (getting fewer but still) where EPSG does not have an official code. In these instances WKT would certainly be appropriate. However, for the vast majority case an EPSG code would suffice, and is far easier to produce and consume. I take the point of self-description. I guess it is a matter of cost Vs benefit for how far you wish to dig down into data definitions. regards -----Original Message----- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Patrick Sunter Sent: Wednesday, 5 October 2011 2:06 PM To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Question on WKT representation of CRS (Bentley, Philip) > (Kennedy, Paul) > 4. Re: Question on WKT representation of CRS (Bentley, Philip) > (Kennedy, Paul) > Message: 4 > Date: Wed, 5 Oct 2011 10:07:48 +0800 > From: "Kennedy, Paul" <p.kenn...@fugro.com.au> > Subject: Re: [CF-metadata] Question on WKT representation of CRS > (Bentley, Philip) > To: "Seth McGinnis" <mcgin...@ucar.edu>, <cf-metadata@cgd.ucar.edu> > Message-ID: <082899b024c30d459ba9acd1c5e58119033a2...@msd9.msd.local> > Content-Type: text/plain; charset="us-ascii" > > Hi > I agree adding something like 'datum = "WGS84" is very easy for > modellers to adopt, but in geodetics terms this is very ambiguous. > While it is simple, it is simply not enough. > > If you want simple, a solid approach is EPSG codes. > > Take a look at the openlayers examples at: > http://trac.osgeo.org/openlayers/wiki/SphericalMercator and > http://docs.openlayers.org/library/spherical_mercator.html > > Openlayers, GoogleEarth, BingMaps, WMS specifications and many others > use the EPSG codes as an unambiguous, brief yet explicit definition of > the underlying geodetic parameters. > > A very good reference for the EPSG / WKT codes can be found at > http://spatialreference.org/ > > The most simple example is WGS84 LatLong (No projection) > > Using EPSG your metadata would need to be: > "EPSG:4326" > > Using WKT your metadata would need to be: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4326"]] > > > Existing CF metadata conventions for CRS definition will cover this > without difficulty. > > If we take spherical mercator as an example (this is still a simple > one!) > > Using EPSG codes your metadata would be: > "EPSG:900913" > > Using WKT you would need the following metadata: > 900913=PROJCS["WGS84 / Simple Mercator", GEOGCS["WGS 84", > DATUM["WGS_1984", SPHEROID["WGS_1984", 6378137.0, 298.257223563]], > PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295], > AXIS["Longitude", EAST], AXIS["Latitude", NORTH]], > PROJECTION["Mercator_1SP_Google"], > PARAMETER["latitude_of_origin", 0.0], > PARAMETER["central_meridian", 0.0], > PARAMETER["scale_factor", 1.0], > PARAMETER["false_easting", 0.0], > PARAMETER["false_northing", 0.0], > UNIT["m", 1.0], AXIS["x", EAST], > AXIS["y", NORTH], > AUTHORITY["EPSG","900913"]] > > This is now stretching the existing CRS specification as defined in CF > convention. > > > Taking a more complex example, the state mapping grid for California. > > Using EPSG codes your metadata would be: > "EPSG:7008, 9822" > > in WKT would be something like: > PROJCS["NAD27 / California Albers", > GEOGCS["NAD27", > DATUM["North American Datum 1927", > SPHEROID["Clarke 1866", 6378206.4, 294.97869821389821, > AUTHORITY["EPSG","7008"]], TOWGS84[-2, 152, 149, 0, 0, 0, 0], > AUTHORITY["EPSG","6267"]], PRIMEM["Greenwich", 0, > AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295, > AUTHORITY["EPSG","9122"]], AXIS["Geodetic latitude", NORTH, > AUTHORITY["EPSG","106"]], AXIS["Geodetic longitude", EAST, > AUTHORITY["EPSG","107"]], > TOITRS["NAD27 to WGS 84 (21)","1249"], AUTHORITY["EPSG","4267"]], > PROJECTION["Albers Equal Area", AUTHORITY["EPSG","9822"]], > PARAMETER["central_meridian", -120], PARAMETER["latitude_of_origin", > 0], PARAMETER["standard_parallel_1", 34], > PARAMETER["standard_parallel_2", 40.5], PARAMETER["false_easting", 0], > PARAMETER["false_northing", -4000000], UNIT["metre", 1, > AUTHORITY["EPSG","9001"]], AXIS["Easting", EAST, > AUTHORITY["EPSG","41"]], AXIS["Northing", NORTH, > AUTHORITY["EPSG","42"]], AUTHORITY["EPSG","3309"]] > > We use WKT for our specification, and it works perfectly fine, but > they can get big. The largest one reported to me was 3Kbytes long. I > tried to dig it out but no luck. > > In summary, my recommendation would be to support EPSG codes for > scientists who require a simple mechanism to define a CRS, but also > permit WKT to be specified in cases where a comprehensive CRS > definition is required. EPSG code "EPSG:4326" would fulfill the vast > majority of cases where basic latitude/longitude from GPS is in use. Just to elaborate a little on EPSG codes vs WKT: the EPSG codes allows you to succinctly summarise a whole CRS, which can map to quite a long WKT. However, it's quite possible to have a dataset that doesn't conform to an existing EPSG since it uses a custom projection - so it's important to have the flexibility to encode the full information. An example use-case we have of this is satellite data downloaded from the WELD project that we want to convert to NetCDF - it's CRS is a custom Albers Equal Area that doesn't have an EPSG code. PROJCS["AEA WGS 1984", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]], PROJECTION["Albers_Conic_Equal_Area"], PARAMETER["standard_parallel_1",29.5], PARAMETER["standard_parallel_2",45.5], PARAMETER["latitude_of_center",23], PARAMETER["longitude_of_center",-96], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] It has ESPG codes for the spheroid and datum defined, but not for the CRS as a whole. I guess an issue with allowing people to only specify EPSG code, is that it tends to go against the 'fully-self-describing' goal of NetCDF CF? Unless you were also saving the parameters as attributes of the grid_mapping variable, or as WKT string. cheers, Patrick. > > regards > pk > > > > > -----Original Message----- > From: cf-metadata-boun...@cgd.ucar.edu > [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth McGinnis > Sent: Wednesday, 5 October 2011 6:50 AM > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Question on WKT representation of CRS > (Bentley, Philip) > > On Tue, 4 Oct 2011 15:28:15 +0100 > Jonathan Gregory <j.m.greg...@reading.ac.uk> wrote: >> >>The CF convention as it stands can say a lot less, but it does look > more >>self-explanatory to me! The meaning of the WKT is not clear to me. I'm > quite >>uneasy about importing a convention into CF which produces opaque > metadata >>like this, even though it is no doubt machine-readable. > > I'm uneasy about opaque metadata, too, especially when it comes to > model output. (I'm agnostic about its use for observational data, or > as an optional add-on.) > > Pragmatically, I think modelers could be asked to add some more > parameters to their projection metadata, things like 'datum = "WGS84"' > or 'ellipsoid = "spherical"', and that would be successful. I think if > they were asked to add something long and mysterious like WKT, there > would be a lot of model output with metadata that's either > non-conformant or flat-out wrong. > > Another consideration, mentioned in a previous thread about datums, is > that the reality of atmospheric models is they generally run on a > spherical earth but use forcings taken from > WGS84 locations without any transformation. So the datum is somewhat > ill-defined in the first place. Would having WKT available for these > cases imply a misleading level of specificity? > > Cheers, > > --Seth > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata