Hi Kyle,
would you have an example where EPSG is insufficient?
The EPSG folks work hard to have a full set of CRS definitions. If you
have a specific one, you can submit it to the committee. They will
review, and if it is indeed unique, it will be added. We have
undertaken this process a couple of times with good outcomes.
regards
From: Kyle Shannon [mailto:kyle at pobox.com]
Sent: Tuesday, 31 July 2012 10:48 AM
To: Kennedy, Paul
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] How to include EPSG codes or WKT information
in a CF file [SEC=UNCLASSIFIED]
In my opinion, what ever solution is chosen, it should be explicitly
defined. EPSG codes aren't enough sometimes and offer no customization.
Whether all parameters are defined, or OGC wkt, at least custom spatial
references can be defined.
On Mon, Jul 30, 2012 at 8:38 PM, Kennedy, Paul <P.Kennedy at fugro.com.au>
wrote:
Hi Etiene,
I understand your goal, and agree it would be an ideal solution to
describe each and every parameter in the geodetic definition. The
trouble is geodesy is not as straight forward as it might be. Different
nations (typically the military) devised different mathematical
solutions to their problem, and these are now set in stone (literally).
If you take a look at New Zealand Map grid, they require a definition of
a 7 parameter transform which brings the total required attributes to 20
to correctly define the CRS....
http://spatialreference.org/ref/epsg/27200/
crs:epsg_code = 27200 //this is sufficient to define NZ map grid using
EPSG codes.
or in WKT it would be:
PROJCS["NZGD49 / New Zealand Map Grid",
GEOGCS["NZGD49",
DATUM["New_Zealand_Geodetic_Datum_1949",
SPHEROID["International 1924",6378388,297,
AUTHORITY["EPSG","7022"]],
TOWGS84[59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993],
AUTHORITY["EPSG","6272"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4272"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
PROJECTION["New_Zealand_Map_Grid"],
PARAMETER["latitude_of_origin",-41],
PARAMETER["central_meridian",173],
PARAMETER["false_easting",2510000],
PARAMETER["false_northing",6023150],
AUTHORITY["EPSG","27200"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
a second, quite different example is the Borneo CRS (used by Shell and
the Gov't)
crs:epsg_code = 29872 //this is sufficient to define the Rectified Skew
Orthomorphic projection using EPSG code.
and the same preresentaiton in WKT...
PROJCS["Timbalai 1948 / RSO Borneo (ft)",
GEOGCS["Timbalai 1948",
DATUM["Timbalai_1948",
SPHEROID["Everest 1830 (1967
Definition)",6377298.556,300.8017,
AUTHORITY["EPSG","7016"]],
AUTHORITY["EPSG","6298"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4298"]],
UNIT["British foot (Sears 1922)",0.3047994715386762,
AUTHORITY["EPSG","9041"]],
PROJECTION["Hotine_Oblique_Mercator"],
PARAMETER["latitude_of_center",4],
PARAMETER["longitude_of_center",115],
PARAMETER["azimuth",53.31582047222222],
PARAMETER["rectified_grid_angle",53.13010236111111],
PARAMETER["scale_factor",0.99984],
PARAMETER["false_easting",1937263.44],
PARAMETER["false_northing",1452947.58],
AUTHORITY["EPSG","29872"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
As you can see, there are specific parameters (rectified_grid_angle,
azimuth, latitude_of_center etc) for this CRS.
I am very much in favour of metadata, but it needs to be achievable, and
I suspect enforcing bespoke CF parameters for geodesy is one step too
far.
>From my perspective I treat an EPSG code as a unit definition (in this
case a coordinate) as I would treat 'metres' as a unit definition for
length. CF conventions do not require the description of what a metre
implies; that is assumed knowledge, and I believe the EPSG code should
be treated likewise. If we make it easy to define the CRS, we will see
far more users actually specify one!
so in summary, I would favour:
Option 1: Long form : full parameter attribution (as per your ticket)
Option 2: Short form : EPSG code
Option 3: Compatibility form : wkt representation
regards
pk
-----Original Message-----
From: Etienne Tourigny [mailto:etourigny.dev at gmail.com]
Sent: Tuesday, 31 July 2012 10:07 AM
To: Kennedy, Paul
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] How to include EPSG codes or WKT information
in a CF file [SEC=UNCLASSIFIED]
On Mon, Jul 30, 2012 at 10:56 PM, Kennedy, Paul <P.Kennedy at fugro.com.au>
wrote:
> Tim,
> I could not agree more. Indeed, I would go even further and permit a
simple EPSG code as a suitable definition of the geodesy. EPSG:4326 is
all you need to specify WGS ellipsoid, datum etc.
>
> crs:epsg_code = 4326 ; //this would be the 99% case. This is how
google openlayers, wms, google, bing and others handle the tricky
subject of geodesy metadata.
Unfortunately, the majority of CF community does not agree with the use
of codes because they are not "self-describable". Have a look at the
archives of this mailing list and you will see a load of threads on this
subject.
If you want EPSG:4326, there are parameters that describe it (see the
link you submitted)
In fact, it is quite compact in CF notation (see example 5/9 of the
CF-1.6 document)
int crs ;
crs:grid_mapping_name = "latitude_longitude";
crs:longitude_of_prime_meridian = 0.0 ;
crs:semi_major_axis = 6378137.0 ;
crs:inverse_flattening = 298.257223563 ;
>
> WKT is also very handy, but harder to generate and parse. I suspect
this is the 1% case.
Thus the need to write the necessary CF parameters to describe WGS84.
This is easier than parsing WKT.
Etienne
>
> http://spatialreference.org/ref/epsg/4326/
>
>
> regards
>
> Paul Kennedy
> Technical Development Manager
> Fugro Survey Pty Ltd
> 24 Geddes St, Balcatta
> Western Australia 6021
> ABN: 81 009 172 990
> Ph : +61 (0)8 6477 4400 <tel:%2B61%20%280%298%206477%204400>
> Direct: +61 (0)8 6477 4418 <tel:%2B61%20%280%298%206477%204418>
> Fax : +61 (0)8 6477 4499 <tel:%2B61%20%280%298%206477%204499>
> Mobile: +61 (0)439 518 265 <tel:%2B61%20%280%29439%20518%20265>
> Email : p.kennedy at fugro.com.au
> Skype : p.kennedy.fugro.com
>
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf
> Of Timothy Hume
> Sent: Tuesday, 31 July 2012 9:34 AM
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] How to include EPSG codes or WKT
> information in a CF file [SEC=UNCLASSIFIED]
>
> Hi Jonathan,
>
> Thanks for the help. I can see that option 80 is probably better, but
option 69 is a lot easier for software developers to bolt onto existing
NetCDF files. Most of the people I talk to don't see why anyone is
interested in anything other than latitudes and longitudes on a
spherical Earth; all the stuff about shape of the Earth etc is
irrelevant to their needs. The truth is, because most of the NWP data I
use is on a rather coarse grid, the grid mapping information is not that
important; two coordinate variables with the longitudes and latitudes is
sufficient for most purposes.
>
> Therefore, the path of least resistance is option 69 (with all its
potential pit falls); I think option 80 will be too much, and a lot of
data writers will simply decide to add no grid mapping information at
all, a worse situation than option 69.
>
> Cheers,
>
> Tim Hume
> Bureau of Meteorology
> ________________________________________
> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of
> Jonathan Gregory [j.m.gregory at reading.ac.uk]
> Sent: Monday, 30 July 2012 7:10 PM
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] How to include EPSG codes or WKT information in
> a CF file [SEC=UNCLASSIFIED]
>
> Dear Tim
>
> There are two open CF trac tickets that relate to this issue,
> proposing to add new conventions to store OGC information in different
> ways in CF. Ticket
> 80 https://cf-pcmdi.llnl.gov/trac/ticket/80 proposes several new
attributes which correspond to WKT elements that currently do not have
grid_mapping equivalents. Ticket 69
https://cf-pcmdi.llnl.gov/trac/ticket/69 proposed to add an attribute to
record the WKT information without translation. Personally I prefer the
former because I am concerned about duplication and possible
inconsistency of information, but please have a look at the tickets and
form your own view, and add comments if you like. So the answer to your
question is that there is not yet a CF standard way to do it, but there
will be.
>
> Best wishes
>
> Jonathan
>
>
> ----- Forwarded message from Timothy Hume <T.Hume at bom.gov.au> -----
>
>> Date: Mon, 30 Jul 2012 11:36:19 +1000
>> From: Timothy Hume <T.Hume at bom.gov.au>
>> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
>> Subject: [CF-metadata] How to include EPSG codes or WKT information
in a CF
>> file [SEC=UNCLASSIFIED]
>>
>> Hi,
>>
>> I am adding grid mapping information to my NetCDF files. My data are
on a lon-lat grid on a spherical Earth. I can put in the standard CF
attributes, grid_mapping_name etc, but also want to include the EPSG and
WKT codes to help software applications that might want these. I have
not been able to find out how this is done in NetCDF-CF, so am using
this format:
>> =
>> int crs ;
>> crs:grid_mapping_name = "latitude_longitude" ;
>> crs:earth_radius = 6371007.0 ;
>> crs:prime_meridian = 0.0 ;
>> crs:epsg_code = 4047 ;
>> crs:wkt = "GEOGCS[\"Unspecified datum based upon the
>> GRS 1980 Authalic Sphere\",DATUM[\"Not_specified_based_on
>> _GRS_1980_Authalic_Sphere\",SPHEROID[\"GRS 1980 Authalic
>> Sphere\",6371007,0,AUTHORITY[\"EPSG\",\"7048\"]],AUTHORITY[\"EPSG\",\
>>
"6047\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"
>> degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[
>> \
>> "EPSG\",\"4047\"]]" ;
>>
>> What do other people do when including this extra grid information?
>>
>> Cheers,
>>
>> Tim Hume
>> Centre for Australian Weather and Climate Research Bureau of
>> Meteorology Melbourne Australia
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ----- End forwarded message -----
> _______________________________________________
> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120731/c3a54a02/attachment-0001.html>
Received on Mon Jul 30 2012 - 20:53:05 BST
