Paul,
I agree epsg has the most comprehensive list/dictionary for srs/crs. My
point is that epsg codes expand into projcs/geogcs/paramaters/etc.
Supporting wkt and expanding epsg into wkt is more robust that just
supporting epsg codes. There are many lambert projections, but how many
have epsg codes? Your link shows quite several srs's with epsg, but
several w/o epsg authority. If ogc wkt(or variables mapped to wkt tags) is
supported, it is easy to assign(#define or read from file) epsg codes to
wkt. I love epsg codes, they make my life super easy, but I always expand
them to ogc wkt or proj.4 format to get the actual data. I use netcdf
every day, and projection information have been an issue since the start.
My application may be on the outside of normal use, though. My $0.02.
kss
On Mon, Jul 30, 2012 at 10:15 PM, Kennedy, Paul <P.Kennedy at fugro.com.au>wrote:
> Kyle,
>
>
>
> EPSG have many lamberts pre-defined. Which area do you have without a
> definition?
>
> You might like to submit it to the EPSG team. I am confident they would
> like to hear from you, and will add it.
>
>
>
> http://spatialreference.org/ref/?search=lambert
>
>
>
> I forgot to mention that EPSG does permit 'custom' codes. We have used
> these in the past. They are typically in the 9000 range. you are free to
> create one, but of course you also need to pass this along the food chain
> so others can consume the CRS.
>
>
>
> regards
>
>
>
>
>
> *From:* Kyle Shannon [mailto:kyle at pobox.com]
> *Sent:* Tuesday, 31 July 2012 11:04 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]
>
>
>
> Setting custom standard paralleles for lamber azimuthal or custom central
> meridians for albers, that sort of thing. It is definitely an exception,
> but I don't see reasons to not allow it. It is easy to expand EPSG codes
> into ogc wkt, but if you had something little different or esoteric, you
> would be out of luck.
>
>
>
> kss
>
>
>
> On Mon, Jul 30, 2012 at 8:53 PM, Kennedy, Paul <P.Kennedy at fugro.com.au>
> wrote:
>
> 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
> > Direct: +61 (0)8 6477 4418
> > Fax : +61 (0)8 6477 4499
> > Mobile: +61 (0)439 518 265
> > 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
>
>
>
>
> _______________________________________________
> 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/20120730/6d96b38c/attachment-0001.html>
Received on Mon Jul 30 2012 - 22:44:34 BST
