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.dev at 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.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:51:46 BST
