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

20020426: netCDF Dimension data (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20020426: netCDF Dimension data (cont.)
  • Date: Fri, 26 Apr 2002 12:36:37 -0600
>From: Steve Parus <address@hidden>
>Organization: University of Michigan
>Keywords: 200204261406.g3QE6Na12557 netCDF dimension variable

Steve,

>My program will be used by other people independently, and I don't think
>(if I understand what you're saying) they will want to first dump a list
>and then decide on a match, etc.

My point was more or less the following: if your software expects
certain names for dimensions and variables, then it will surely break
when trying to use a file that has different names for the same
dimensions and variables.  One way around this is to build in the
reading of an auxiliary information file (table) that has the
information on the mapping of what your program expects and what the
netCDF contains.  The other thing that a number of developers have done
is make their applications general to the point of extracting the
information on what dimensions and variables are in the netCDF being
read and then present an interface to the user so that s/he can select
the one s/he wants to work with.

>This raises another question.  Are there licensing or royalty issues with
>using your DLL in commercial for-sale software ?

Please review our copyright notice for the netCDF:

http://www.unidata.ucar.edu/packages/netcdf/copyright.html

This explains how the software may be used in freely-available and
licensed (commercial) applications.

Also, please take a look at the list of commercial packages that are
already using the netCDF:

http://www.unidata.ucar.edu/packages/netcdf/software.html

While not an exhaustive list of all applications that use netCDF, this
should give you an idea of how widely it is being used.

>Another alternative is for me to get at the data by decoding the binary
>file structure instead of using the dll.  I suppose there's the possibility
>that file structure (offsets, etc) might change somewhere in the future.

Yes, there is that possibility.  The current netCDF file structure is,
however, documented:

http://www.unidata.ucar.edu/packages/netcdf/guide_15.html#SEC115

Since the idea of the netCDF is an API (Application Programming Interface),
we typically try to steer users away from direct access to the file.
You can do it, however.

>That would make my non-dll code not function.   I assume though that the
>dll would be changed to accomodate this, and users could simply be sent or
>acquire that new dll and my program would not have to change ?

Yes, your assumption is correct.

Tom