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. regards pk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Seth McGinnis Sent: Wednesday, 5 October 2011 6:50 AM To: [email protected] Subject: Re: [CF-metadata] Question on WKT representation of CRS (Bentley, Philip) On Tue, 4 Oct 2011 15:28:15 +0100 Jonathan Gregory <[email protected]> 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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
