-- Richard P. Signell U.S. Geological Survey Phone: (508) 457-2229 384 Woods Hole Road Fax: (508) 457-2310 Woods Hole, MA 02543-1598 Denis Nadeau wrote: > Steve, > > I have finished the projection part of NetCDF with the same approach. > It is not checked in yet, but I am planning to do so today. I have > created and computed the following metadata. > > Attributes: > Northernmost_Northing (These attributes are used only if there is no > GeoTransform array.) > Southernmost_Northing > Easternmost_Easting > Westernmost_Easting > > GeoTransform (this is the GDAL adfGeoTransform array ) > > spatial_ref (this is the WKT you called esri_pe_string ); > > Denis > > 2006/4/28, Steve Kopp <skopp at esri.com <mailto:skopp at esri.com>>: > > Denis, > > > > After discussions with John last year, this is the same approach we > have taken with ArcGIS when exporting to netCDF, and so far it is > working well for us. > > > > When we export to a netCDF file we write projection information as > an attribute of a variable. We call the attribute "esri_pe_string". > Of course we are reading and writing the CF standard projection > information when it is a coordinate system supported by CF. > > > > Steve > > > > float wdemclputm(y, x) ; > > wdemclputm:long_name = "wdemclputm" ; > > wdemclputm:esri_pe_string = > "PROJCS[\"Clarke_1866_UTM_Zone_12N\",GEOGCS[\"GCS_Clarke_1866\",DATUM[\"D_Clarke_1866\",SPHEROID[\"Clarke_1866\",6378206.4,294.9786982]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\", > 0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"False_Easting\",500000.0],PARAMETER[\"False_Northing\",0.0],PARAMETER[\"Central_Meridian\",-111.0],PARAMETER[\"Scale_Factor\", > 0.9996],PARAMETER[\"Latitude_Of_Origin\",0.0],UNIT[\"Meter\",1.0]]" ; > > > > > > ------------------------------------------------------------------------ > > *From:* owner-galeon at unidata.ucar.edu > <mailto:owner-galeon at unidata.ucar.edu> [mailto: > owner-galeon at unidata.ucar.edu > <mailto:owner-galeon at unidata.ucar.edu>] *On Behalf Of *Denis Nadeau > *Sent:* Thursday, April 27, 2006 6:51 AM > *To:* John Caron > *Cc:* galeon at unidata.ucar.edu <mailto:galeon at unidata.ucar.edu>; CF > *Subject:* Re: GDAL NetCDF driver and projection. > > > > Hi John, > > Thank you for taking the time to write this email. Your points are > very clear, and they are very helpful. I must tell you that you > give me information and that you sure taught me about CF-1 > convention community . I will keep your email as a reference when > coding the GDAL NetCDF driver. > > I have decided to use WKT to encode projections and if I see a new > governance structure from CF checked in, I will update the driver. > As well, I think for this time being I will relax the lat,lon array > requirements. If needed by the community, it would be very easy to > compute, but I do not want the driver to be expensive in CPU and space. > > Thanks again, > > Regards, > Denis > > 2006/4/26, John Caron <caron at unidata.ucar.edu > <mailto:caron at unidata.ucar.edu>>: > > Hi Denis: > > 1) CF has unfortunately not yet dealt with datum and spheroid > encoding (not sure what "authority" is), but its on our list to > tackle. CF does specify a list of known projections and how to > encode those (Appendix F). > > 2) You can, of course, add any metadata you want, eg GeoTransform > values, from the CF POV, which CF readers are likely to ignore. > > 3) Frank Warmerdam and I talked a while ago about using WKT to > encode projection info. At the moment, it seems as good as any, with > the proviso that the CF group may decide to do it another way (when > we eventually decide). > > 4) Calculating the lat,lon arrays for projections is currently > required under CF. I have proposed that this requirement be relaxed, > perhaps as a CF profile, for the case where this is unneeded and > burdonsome. Issues like this are awaiting a new CF governence structure. > > 5) Unidata's software maps OPeNDAP datasets into the NetCDF data > model (aka "Common Data Model"), so we strongly encourage everyone > to use the NetCDF metadata conventions such as CF in their OPeNDAP > Servers. We think of OPeNDAP datasets as remote NetCDF datasets, and > make access to them as transparent as possible. > > 6) BTW, CF is an organization independent of Unidata. It grew out of > "climate and forecasting" modelers using NetCDF files, but is now > broader than that, and is an exemplar "community of practice" around > scientific metadata. > > I am cc'ing to the CF list in case anyone there wants to add more, > and so the list can hear about what you are trying to do. In case > anyone doenst know, GDAL is an excellent C library for geospatial > work, kind of a "Common Data Model" for C . > > > Denis Nadeau wrote: >> Hi, >> >> I have looked at the DODS OpeNDAP site and I could use the same > metadata >> structure to store NetCDF projection information. This way if > somebody >> needs to convert from GTIFF to NetCDF, all projecton information could >> be used by GRADS, Openev or other applications. I guess my main > problem >> is related on how the CF-1 convention from Unidata handle > projections. >> This bring me to a main question: >> >> What are the needs for projections in the GALEON projects? >> >> I am the current GDAL NetCDF driver programmer, and would like to make >> the driver as useful as it can be to the community. >> >> Thanks, >> Denis >> >> >> Here are some notes on what was planned for storing projection, > etc in >> other parts of GDAL drivers. To my knowledge, the never really >> propogated >> through to the OPeNDAP driver. If the NetCDF or HDF direct > access GDAL >> driver is updated that those changes propogate through to the > OPeNDAP >> driver so that the same NetCDF/HDF datasets are accessible via > native >> OPeNDAP server, Grads GDS and THREDDS. >> >> At this point, a lot more support is there for local NetCDF/HDF >> files than >> for support of those files through OPeNDAP. Its on my rather > large >> to do >> list, but somewhere in the 2 year timeframe. >> >> http://home.gdal.org/~warmerda/gdal_opendap_design.html > <http://home.gdal.org/%7Ewarmerda/gdal_opendap_design.html> (GeoTiff) >> http://gdal.maptools.org/frmt_dods.html >> <http://gdal.maptools.org/frmt_dods.html > <http://gdal.maptools.org/frmt_dods.html>> (DODS/OPeNDAP) >> >> Thanks! >> Rob >> >> On Wed, April 26, 2006 5:32 am, Denis Nadeau wrote: >> > Hi All, >> > >> > I would like to have suggestions from the community on the >> current needs >> > for the GDAL NetCDF driver. I am currently writing the > CreateCopy >> method to >> > allow people to convert from any GDAL supported format to > NetCDF CF-1 >> > convention format. >> > >> > At this point I am stuck with projection issues. How should > I handle >> > DATUM, >> > SPHEROID and AUTHORITY? I can produce a lat lon arrays to >> reproject the >> > projected coordinates to lat/lon space but that may be expensive >> in cpu >> > and >> > space. >> > >> > I am thinking as well to create an array containning the >> GeoTransform >> > values >> > if found in the source file. >> > >> > adfGeoTransform[0] /* top left x */ >> > adfGeoTransform[1] /* w-e pixel resolution */ >> > adfGeoTransform[2] /* rotation, 0 if image is "north up" */ >> > adfGeoTransform[3] /* top left y */ >> > adfGeoTransform[4] /* rotation, 0 if image is "north up" */ >> > adfGeoTransform[5] /* n-s pixel resolution */ >> > >> > >> > Thanks for your suggestion, >> > >> > Best Regards, >> > Denis Nadeau >> > >> >> >> -- >> Alaska Ocean Observing System >> Database Manager >> 907-474-7948 >> >> > =============================================================================== > >> >> To unsubscribe galeon, visit: >> http://www.unidata.ucar.edu/mailing-list-delete-form.html >> > =============================================================================== > >> >> >> > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadataReceived on Mon May 01 2006 - 10:45:25 BST
This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST