Anthony has graciously and rapidly created an account for me (I sent an email to webmaster@)
Thanks, Etienne On Tue, Dec 13, 2011 at 7:40 PM, Karl Taylor <[email protected]> wrote: > Hi Jeff, > > Do you know how Etienne can get access to trac? > > thanks, > Karl > > On 12/13/11 9:35 AM, Etienne Tourigny wrote: > > Jon, > > thanks for your answers > > On Tue, Dec 13, 2011 at 1:42 PM, Jonathan Gregory > <[email protected]> wrote: > > Dear Etienne > > Thanks for your helpful email, and sorry for slow response. > > Ok you mean that we could add new projections easily to the CF > standard? That's great to know. > > Yes, you could do this with a trac ticket, like ticket 72, which proposes to > add the geos projection. See https://cf-pcmdi.llnl.gov/trac/query > > I would love to add a trac ticket, but unfortunately my repeated > requests to webmaster to get a trac id have failed... who should I > ask? > > I'm not sure I understand your question - do you mean to ask if these > additions to CF would be sufficient to describe most WKT definitions > in pure CF metadata (without the WKT)? > > Yes, that's what I mean. I'm interested to know how many other elements of > WKT > are used in the cases you deal with. > > It seems that > for many applications (especially at the scale most netcdf files are > used for), TOWGS84 parameters are sufficient. A named datum would be > nice, but there are quite a few different ways to identify datums (OGC > vs ESRI). > > OK. If they are standardised lists, we could provide attributes to store > them in. > > This page is very informative on WKT specifications > http://home.gdal.org/projects/opengis/wktproblems.html > > TOWGS84 corresponds to the Bursa Wolf parameters for datum shifts and > is standard in CT 1.0 using (3 or 7 values). > > The CT 1.0 standard is relatively simple and fairly complete, I would > suggest that CF should use it to fill the gaps in projection > definitions. > http://www.opengeospatial.org/standards/ct > > CT 1.0 WKT stores the datum's name, EPSG code as well as its relation > to the WGS84 datum in TOWGS84. > > For example, the full WKT for EPSG:4618 (that uses SAD69 datum) is: > > GEOGCS["SAD69", > DATUM["South_American_Datum_1969", > SPHEROID["GRS 1967 Modified",6378160,298.25, > AUTHORITY["EPSG","7050"]], > TOWGS84[-57,1,-41,0,0,0,0], > AUTHORITY["EPSG","6618"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4618"]] > > In the DATUM section you see the datum name > "South_American_Datum_1969", EPSG code 6618 and > TOWGS84[-57,1,-41,0,0,0,0] > > > The Simple Features specification only stores datum_name, which can be > problematic as some vendors (i.e. ESRI) use slightly different datum > names than others (i.e. OGR, CADCorp). I prefer the later as it > follows EPSG datum names more closely. > > > => In light of all this, could we add datum_name, datum_code and > towgs84 to grid_mapping? > > As maintainer of GDAL's netcdf driver, I see that the only thing > missing in the WKT/CF transformation is named datum (and ideally datum > code and towgs84), then there would not be any need to keep the entire > WKT string - with some exceptions where the parameters are not 100% > compatible (see the link below). > > For example, the same EPSG:4618 WKT translates to CF like this: > > crs:grid_mapping_name = "latitude_longitude" ; > crs:longitude_of_prime_meridian = 0. ; > crs:semi_major_axis = 6378160. ; > crs:inverse_flattening = 298.249999999996 ; > crs:spatial_ref = > "GEOGCS[\"SAD69\",DATUM[\"South_American_Datum_1969\",SPHEROID[\"GRS > 1967 > Modified\",6378160,298.249999999996,AUTHORITY[\"EPSG\",\"7050\"]],TOWGS84[-57,1,-41,0,0,0,0],AUTHORITY[\"EPSG\",\"6618\"]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433],AUTHORITY[\"EPSG\",\"4618\"]]" > ; > crs:GeoTransform = "-80 0.25 0 -10 0 -0.25 " ; > > The spatial_ref is kept for now because CF lacks information on the > named datum. It would be complete if we could have something like: > > crs:grid_mapping_name = "latitude_longitude" ; > crs:longitude_of_prime_meridian = 0. ; > crs:semi_major_axis = 6378160. ; > crs:inverse_flattening = 298.249999999996 ; > crs:datum_name = South_American_Datum_1969 ; > crs:datum_code = 6618; > crs:towgs84 = -57,1,-41,0,0,0,0 ; > > Perhaps there should be an additional parameter (like datum_authority) > to specify that datum_code is from EPSG, or make it a string like > 'EPSG:6618' > > Here is a small compilation of the compatabilities between WKT (as > GDAL sees it) and CF-1.5 projections, there are a few > problems/unknowns with some projections: > http://trac.osgeo.org/gdal/wiki/NetCDF_ProjectionTestingStatus > > If you identify errors or inadequacies with CF definitions from your > detailed > analysis, you could propose they be corrected, again with a CF trac ticket, > in > this case as a "defect" rather than an addition to the standard. > > I'll look into this when I have the time... and if I can get access to > trac!!! > > The following page lists WKT parameters: > http://www.geoapi.org/2.0/javadoc/org/opengis/referencing/doc-files/WKT.html > > Yes, this is a useful page. > > There are a few other parameters like VERT_CS, COMPD_CS and VERT_DATUM > that some users may need. > > The VERT_CS and VERT_DATUM appear to be names (in the Newlyn example). Are > these names standardised? > > They are part of CT 1.0 , I suggest you take a look at the WKT > keywords. Sorry but I don't know more to comment extensively. > > Thank you Jonathan! > Etienne > > Best wishes and thanks for your help > > Jonathan > > _______________________________________________ > 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
