Dear Paul,
Sorry that you were unable to get an account. When it comes to
under-funded efforts, a little persistence usually gets rewarded in the
end. If you are still interested in contributing, please let me know.
regards,
Karl
On 12/13/11 3:46 PM, Kennedy, Paul wrote:
> Hi
> Lucky you. I attempted to get an account a few weeks back, but got no
> response, so I was precluded from contributing, which is a pity as we
> have dedicated geodesists who have decades of experience in this field.
>
> I guess the webmaster is too busy.
>
> Regards
>
> Paul Kennedy
> Technical Development Manager
> Fugro Survey Pty Ltd
> 24 Geddes St, Balcatta
> Western Australia 6021
>
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Etienne Tourigny
> Sent: Wednesday, 14 December 2011 5:51 AM
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Question on WKT representation of CRS
>
> 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\"]],TOWGS8
> 4[-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
>>
> _______________________________________________
> 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/20111213/5f6feff6/attachment-0001.html>
Received on Tue Dec 13 2011 - 17:07:28 GMT
