Hi Paul,
Great to hear that.
I'm thinking of a compound CRS with WGS84 and geoid height. I feel scary
finding EPSG:4979 often used in experiments of aviational meteorology data,
since that is for ellipsoid height. I don't want to see an airplane hit the
terrain when the pilot believes being 200ft agl.
Back to the topic: I think registry codes like EPSG should be recommended
(in comparison to ad-hoc WKT) if the registration is not so much more
difficult than that for CF standard_name.
Best,
--
TOYODA Eizi,
----- Original Message -----
From: "Kennedy, Paul" <p.kenn...@fugro.com.au>
To: "TOYODA Eizi" <toy...@gfd-dennou.org>; "Patrick Sunter"
<patdeve...@gmail.com>; <cf-metadata@cgd.ucar.edu>
Sent: Wednesday, October 05, 2011 11:18 PM
Subject: RE: [CF-metadata] Question on WKT representation of CRS
(Bentley,Philip) > (Kennedy, Paul)
Hi
nope (for me at least!). We do it regularly. I can put you on to the
guy in our shop who knows the procedure very well.
regards
pk
-----Original Message-----
From: TOYODA Eizi [mailto:toy...@gfd-dennou.org]
Sent: Wednesday, 5 October 2011 10:16 PM
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
