> 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
