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>:
>
> 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] *On Behalf Of *Denis Nadeau
> *Sent:* Thursday, April 27, 2006 6:51 AM
> *To:* John Caron
> *Cc:* 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>:
>
> 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 > (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
> >
> ===============================================================================
>
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060428/cc9f6199/attachment-0002.html>
Received on Fri Apr 28 2006 - 09:38:14 BST
