[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDAL NetCDF driver and projection.





Ben Domenico wrote:
John,

Please excuse this very fundamental question, but I haven't found an answer in the various documents I've been reading. Does CF dictate that the coordinate system data will always be enumerated in arrays within the netCDF?

Yes, netcdf doesnt really have any other way to express coordinate values, 
other than by putting them into arrays. However, projection functions (eg CF 
appendix F) do encode mappings between coordinate values and (lat, lon) so 
thats sort of another way.

Typically "curvilinear coordinates" in the context of netcdf means that you 
need 2D variables, instead of 1D variables.

Also, is there a better place to read about this than the
the following document I've been using?

   http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html

Not really. Section 3.2 of

 ftp://ftp.unidata.ucar.edu/pub/netcdf-java/v2.2.14/NetcdfJavaUserManual-2.2.doc

may be useful.

An old attempt at a formal treatment is:

 http://www.unidata.ucar.edu/staff/caron/papers/CoordMath.htm

which you may be able to skim and get something out of.



-- Ben

On 4/26/06, * John Caron* <address@hidden <mailto:address@hidden>> wrote:

    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 (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
> ===============================================================================

     >
     >
     >

    
===============================================================================
    To unsubscribe galeon, visit:
    http://www.unidata.ucar.edu/mailing-list-delete-form.html
    <http://www.unidata.ucar.edu/mailing-list-delete-form.html>
    
===============================================================================