Anthony has graciously and rapidly created an account for me (I sent
an email to webmaster_at_)
Thanks,
Etienne
On Tue, Dec 13, 2011 at 7:40 PM, Karl Taylor <taylor13 at llnl.gov> 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
> <j.m.gregory at reading.ac.uk> 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
> 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 Dec 13 2011 - 14:50:48 GMT
