NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

netCDF Utilities

Steve Emmerson <steve@xxxxxxxxxxxxxxxx> writes as follows in
>Message-Id: <199204291912.AA12751@xxxxxxxxxxxxxxxx>
dated Thu Apr 30 05:37:43 1992
>
>Both ncdelete(1) and nccopy(1) can be implemented in terms of
>ncextract(1), which is about to be released.
>
>>In my previous posting I proposed a syntax for specifying an 'array' defined
>>by netcdf filename, variable name & a vector of subscripts for each dimension.
>
>This is nice and elegant solution.  Unfortunately, it has the drawback
>of requiring that a layer be created which is capable of interpreting
>such netCDF specifications in the manner you suggest.  This would mean
>that no netCDF operators could be released until the interpreter was
>fully completed (or as near enough as makes no difference).  This is in
>contrast to the current proposal of implementing stand-alone netCDF
>programs and releasing them as they are completed.
>
>Personally, I'd be more than happy to work on such a netCDF
>specification interpreter (I've thought about one for some time).  I
>think it makes sense, especially as the first step towards a potential
>`netCDF data-server' and as an interface for converting between how
>data exists in a netCDF object and what an individual program wants to
>see.  I think, however, that it will take some hewing and crying from
>the netCDF user-community to convince the powers that be that they
>should set these wheels in motion.  Note that the preceding is just my
>opinion and not necessarily the UPC's (which I don't think has an
>opinion on this).

I have now implemented most of my 'array' syntax. It really was pretty easy.
I considered using lex and/or yacc, but ended up just doing it in c.

My procedure parse_nc_array does the required parsing & is complete.
However I have not yet written code to fully use the output from
parse_nc_array.

Some examples of array specifications parsed by parse_nc_array are:

"ocean.cdf;vec[6:7,2]"
This refers to elements 6 to 7 & 2 of variable 'vec'. Note that origin 1
is used so that c subscripts are 5, 6, 1. No coordinate variable name is
specified so the 1st is implied (i.e. the one corresponding to position in
specification)

"ocean.cdf;sst[year=6;latitude=1:56;longitude=~-90 degrees_east:]"
Here coordinate variable 'year' has c index 5, coordinate variable
'latitude' has c index from 0 to 55, coordinate variable 'longitude' starts
at nearest value to -90 degrees_east & goes to end.

"ocean.cdf; sst[ year=6,7,9; latitude=+1:+3; longitude=:3:2,9: ]"
Here coordinate variable 'year' has c index 5,6,8, coordinate variable
'latitude' has c index from 1 beyond current size of unlimited dimension to 
3 beyond current size of unlimited dimension, coordinate variable 'longitude'
has c index 0, 2 then 8 to end.

You can access code by anonymous ftp to atmos.dar.csiro.au
followed by "cd netcdf/hld". Procedure parse_nc_array is in file nc.h
& is called by program in file nc_put_var.c
followed by "cd netcdf/hld"

My main point is that it really is quite easy to implement this sort of 
syntax. If we can agree on some syntax, I would consider adapting my code, so
you can use it.

Would you please give further details about ncextract & other utiilites you are
planning?

Harvey Davies,
CSIRO Division of Atmospheric Research,    Voice: +61 3 586 7574
Private Bag No. 1, Mordialloc,               Fax: +61 3 586 7600
Victoria 3195,  Australia               Internet: hld@xxxxxxxxxxxx



  • 1992 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: