An additional benefit of using PROJ.4 strings is that the proj open-source library (http://trac.osgeo.org/proj/) can be easily used for coordinate transformations, either with a C API or with a command-line tool (cs2cs).
For example, GDAL and mapserver use PROJ.4 for its coordinate transformations. For details on how EPSG codes can be used to create a PROJ.4 string: http://trac.osgeo.org/proj/wiki/FAQ#HowdoIuseEPSGcoordinatesystemcodeswithPROJ.4 http://mapserver.org/mapfile/projection.html However, the automatic translation of EPSG codes to PROJ.4 strings requires a proj installation and its support files, and there is a somewhat imperfect translation in some cases. regards, Etienne On Wed, Oct 5, 2011 at 12:35 AM, Etienne Tourigny <etourigny....@gmail.com> wrote: > 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.kenn...@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-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
