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:[email protected]] Sent: Tuesday, 31 July 2012 11:04 AM To: Kennedy, Paul Cc: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Tuesday, 31 July 2012 10:48 AM To: Kennedy, Paul Cc: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Tuesday, 31 July 2012 10:07 AM To: Kennedy, Paul Cc: [email protected] 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 <[email protected]> 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 : [email protected] > Skype : p.kennedy.fugro.com > > > > -----Original Message----- > From: CF-metadata [mailto:[email protected]] On Behalf > Of Timothy Hume > Sent: Tuesday, 31 July 2012 9:34 AM > To: [email protected] > 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 [[email protected]] On Behalf Of > Jonathan Gregory [[email protected]] > Sent: Monday, 30 July 2012 7:10 PM > To: [email protected] > 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 <[email protected]> ----- > >> Date: Mon, 30 Jul 2012 11:36:19 +1000 >> From: Timothy Hume <[email protected]> >> To: "[email protected]" <[email protected]> >> 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
