Sounds good.
We prefaced ours with esri_pe_string because it has some small differences from the official GML WKT.
I'll spend some time looking into be able to read both representations. Might not make it into ver 9.2 since we've wrapped development on it but should at least have it in the next release followin that.
Steve
-----Original Message-----
From: Denis Nadeau [mailto:denis.nadeau at gmail.com]
Sent: Fri 4/28/2006 8:38 AM
To: Steve Kopp
Cc: John Caron; galeon at unidata.ucar.edu; CF
Subject: Re: GDAL NetCDF driver and projection.
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/1d8e9344/attachment-0002.html>
Received on Fri Apr 28 2006 - 13:03:06 BST
