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
Received on Wed Oct 05 2011 - 02:56:32 BST
