> ? 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
>
>
Received on Wed Oct 05 2011 - 00:05:54 BST
