⇐ ⇒

[CF-metadata] Question on WKT representation of CRS (Bentley, Philip) > (Kennedy, Paul)

From: Pop, Zamfir FCIH <ZPop>
Date: Wed, 5 Oct 2011 10:34:08 -0500

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-bounces at cgd.ucar.edu
[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of TOYODA Eizi
Sent: Wednesday, October 05, 2011 9:16 AM
To: Kennedy, Paul; Patrick Sunter; cf-metadata at 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.eizi at gmail.com
----- Original Message -----
From: "Kennedy, Paul" <P.Kennedy at fugro.com.au>
To: "Patrick Sunter" <patdevelop at gmail.com>; <cf-metadata at 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-bounces at cgd.ucar.edu
[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Patrick Sunter
Sent: Wednesday, 5 October 2011 2:06 PM
To: cf-metadata at 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.Kennedy at fugro.com.au>
> Subject: Re: [CF-metadata] Question on WKT representation of CRS 
> (Bentley, Philip)
> To: "Seth McGinnis" <mcginnis at ucar.edu>, <cf-metadata at cgd.ucar.edu>
> Message-ID: <082899B024C30D459BA9ACD1C5E58119033A2284 at 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-bounces at cgd.ucar.edu 
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Seth McGinnis
> Sent: Wednesday, 5 October 2011 6:50 AM
> To: cf-metadata at 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.gregory at 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 at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata 
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Oct 05 2011 - 09:34:08 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒