Hi all,
If aiming for more simplicity, perhaps PROJ.4 strings would be more
interesting.
http://trac.osgeo.org/proj/wiki/FAQ
The advantages or PROJ.4 is that projection and datum can be expressed
in relatively compact format, and you can alternatively plug in an
EPSG code for simplicity.
There are also no obscure authority codes which can cause confusion.
PROJ.4 can be strings can be initialized from EPSG codes such as the
following: +init=epsg:4326
The more common usage is to specify the projection with all its
parameters, in a "self describing" manner.
e.g. +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
or: +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
I would recommend the usage of PROJ.4 so it can be used by modelers
with the simple "+init=epsg:4326", and the more verbose syntax when
needed.
PROJ.4 strings for previous examples are written below inline.
regards, Etienne
On Tue, Oct 4, 2011 at 11:07 PM, Kennedy, Paul <P.Kennedy at fugro.com.au> wrote:
> 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"]]
>
http://spatialreference.org/ref/epsg/4326/
+init=EPSG:4632
or
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
>
> 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.
>
Google Mercator is more supported with EPSG:3857
http://spatialreference.org/ref/sr-org/6864/
+init=epsg:3857
or
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
>
> 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"]]
>
http://spatialreference.org/ref/epsg/3309/
+init=epsg:3309
or
+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
+y_0=-4000000 +ellps=clrk66 +datum=NAD27 +units=m +no_defs
> 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: 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 Tue Oct 04 2011 - 21:35:16 BST
