NCL Home > Documentation > Manuals > Reference

Information on supported data formats

This page provides more detailed information about each of the supported data formats in NCL. Information about referencing files and file variables is provided in the Files and file variables section of the reference guide. Everything discussed in that section applies to all supported data formats regardless of type. The discussion here focuses on specific conventions and limitations of each format and its NCL implementation. The most detailed discussion involves the GRIB format, because of all the supported formats, it has required the most work to recast into a NetCDF-like model.

NCL's supported data formats are:

NetCDF - Network Common Data Format

Online documentation for NetCDF is available at http://www.unidata.ucar.edu/packages/netcdf/index.html.

NCL offers read and write access to existing NetCDF files as well as the ability to create NetCDF files from scratch. Nearly all the NetCDF features are supported by NCL because NCL's data model is patterned after NetCDF.

As of version 4.3.1 or later, NCL provides support for "classic" mode NetCDF version 4.0 files. These files are restricted to the same interface provided by earlier versions of NetCDF, but like all NetCDF 4 files, use HDF 5 for the underlying storage format. The main advantage of "classic" mode is that it allows access to the built-in data compression provided by HDF 5, which in many cases can dramatically reduce overall file sizes.

The procedure filedimdef can be used to create file dimensions that are unlimited, and the procedure filevardef can be used to pre-define variables. Global file attributes can be written to NetCDF files by assigning attributes to the variable that references the file, in the same way that attributes are assigned to normal NCL variables. Doing this causes NCL to write the attribute into the file.

Beginning with version 6.1.1, NCL provides beta-level support for the complete NetCDF 4 data model. It supports all the NetCDF4 data types including string, vlen, compound, enum, and opaque, as well as features like groups, chunking, compression (available since version 4.3.1), and caching. All known issues in the alpha version of the NetCDF4 interface included with NCL 6.1.0 have been fixed. See the "What's new with the current release" for more detailed information.

File options

The setfileoption procedure allows access to a number of NetCDF-specific options.
  • The "Format" option allows the user to create NetCDF files with 64-bit file offsets, allowing much larger variables and files than the "classic" NetCDF format. Note that this option only needed when creating new files. NCL automatically recognizes the large file format when it opens an existing file. As of version 4.3.1 or later, the "Format" option accepts the value "NetCDF4Classic" to specify the creation of a NetCDF 4 "classic" mode file.

    Beginning with version 6.1.0, the "Format" option accepts the value "NetCDF4" to specify the creation of non-classic-model NetCDF 4 files. With this new option, the file size and variable size are both unlimited and the complete NetCDF4 data model is supported.

  • There are several options, including "DefineMode", "HeaderReverseSpace", "PreFill", and "SuppressClose", that can help improve performance, in some cases by orders of magnitude, when writing new data to files that are already large, or contain many attributes and variables.

  • The option "MissingToFillValue" is a convenience feature that provides a virtual _FillValue attribute in cases where variables have only a missing_value (conformant with the COARDS convention).

  • Available in version 4.3.1 and later. The option "CompressionLevel" specifies the desired compression level on a scale of 0 through 9. This option is ignored unless "Format" is set to "NetCDF4Classic" or to "NetCDF4"

Data model differences

Even though NCL's data model is based on NetCDF, there are some differences:
  • While NCL has a string data type, classic model NetCDF does not. Within the NCL environment NetCDF attributes of type character are mapped into type string for convenience. However, when writing to NetCDF the conversion function stringtochar must be used to write NCL string data into NetCDF files.

  • Both NCL and NetCDF have always had a byte data type but in NCL the byte type was unsigned (all values non-negative in the range 0-255), whereas in NetCDF it has always been signed (values ranging from -128 - +127). In version 6.0.0, NCLs changed the byte type to a signed type in order to be more consistent with NetCDF. NCL has also added the ubyte type as a new unsigned type, matching the type of the same name that was added to NetCDF4.

  • NCL treats scalars and arrays with a single element as interchangeable, but NetCDF distinguishes scalars, which have no dimensions, from arrays, which must have one or more named dimensions. NetCDF scalar variables show up in the NCL environment as variables with a single-element dimension with the pre-defined name "ncl_scalar". In order to write a scalar to a NetCDF file, you must first assign it the dimension name "ncl_scalar", either using the procedure filevardef or by directly assigning the dimension name "ncl_scalar" to a single element NCL variable prior to assigning it to a file variable. Since "ncl_scalar" is a pre-defined file dimension name, it is an error to try to create a dimension with this name in a file. For examples of writing scalar values to a file see filevardef example 2.

HDF - Hierarchical Data Format - Scientific Data Sets (SDS only)

Online documentation for HDF is available at http://www.hdfgroup.org/products/hdf4/.

NCL has interfaces that understand a subset of the content available in HDF4-formatted files. NCL can read and write data that uses the SDS (Scientific Data Set) interface. Opening an HDF file in the NCL environment is entirely analogous to opening a NetCDF file as documented above, with some minor exceptions.

  • The first thing you will probably notice when you attempt to print the contents of an HDF file object is that HDF files often begin with voluminous multiline global attributes. Some of this information contained in these attributes may be useful, but much of it is not of much concern to persons only interested in getting at the data.

  • Since the HDF format allows variables with spaces and other non-alphanumeric characters, NCL must change the variable names to make them into names that are fully accessible in the NCL environment. It does this by changing all characters that are invalid for an NCL file variable name into the underscore ('_') character. To compensate for this possible loss of information, NCL provides an attribute for each variable, called hdf_name, that contains the name exactly as it appears in the HDF file. This attribute is redundant in cases where the actual HDF name is valid as an NCL variable name.

  • NCL has a read-only ability to understand HDF Vgroups. When a variable that is part of a Vgroup is encountered, NCL appends a double underscore and the group number to the end of the variable name. This ensures that the variable will have a unique name, relative to variables that belong to other Vgroups. It also provides two additional attributes to the variable: hdf_group, whose value is the HDF string name of the group, and hdf_group_id, whose value is the same as the group number appended to the end of the variable name.

  • There is currently no way to access 8-bit and 24-bit HDF images from NCL. There is also no access to the HDF VDATA interface.

HDF5 - Hierarchical Data Format

Online documentation for HDF5 is available at http://www.hdfgroup.org/HDF5/doc/doc-info.html.

NCL has interfaces that understand a subset of the content available in HDF5-formatted files. NCL can read (and limited ability to write) data. Opening an HDF5 file in the NCL environment is entirely analogous to opening a NetCDF file as documented above, with some minor exceptions.

  • The first thing you will probably notice when you attempt to print the contents of an HDF5 file object is that HDF5 files often begin with voluminous multiline global attributes. Some of this information contained in these attributes may be useful, but much of it is not of much concern to persons only interested in getting at the data.

  • Since the HDF5 format allows variables with spaces and other non-alphanumeric characters, NCL must change the variable names to make them into names that are fully accessible in the NCL environment. It does this by changing all characters that are invalid for an NCL file variable name into the underscore ('_') character. To compensate for this possible loss of information, NCL provides an alternate way to access such variable, which user $ (dollar-sign) to quota the name exactly as it appears in the HDF5 file.

  • NCL has a read-only ability to access a 'group' in HDF5 by using the '=>' operator. The new group functions similar to a file, with file attributes, but only contains the group's properties (datsets, groups, attributes, etc) only belong to this group. User can use this group same as a file.

HDF-EOS - Hierarchical Data Format - Earth Observing System (GRID and SWATH only)

Online documentation for HDF-EOS is available at http://hdfeos.org.

NCL provides limited read-only access for SWATH and GRID data groups in HDF-EOS files. POINT data groups are currently ignored. As with all NCL's supported formats, HDF-EOS files are read into file variables that use NetCDF-like conventions.

Non-alphanumeric characters in HDF-EOS variable names are replaced the '_' character when listed from NCL and are referenced from NCL in this fashion. Note that due to the hierarchical structure of HDF files, variables with the same name can appear in different groups. Since NCL's NetCDF-like interface flattens this hierarchy, it appends the group name, preceded by an underscore, to all variable names in order to ensure that each variable name is unique within the context of the NCL file variable.

HDF-EOS5 - - HDF5 - Earth Observing System (Fully support GRID, SWATH and ZA, limited on POINT)

Online documentation for HDF-EOS5 is available at http://www.hdfeos.org.

NCL provides limited read-only access for SWATH, GRID, and ZA data groups in HDF-EOS5 files. POINT data groups are currently limited to accessing the headers only. As with all NCL's supported formats, HDF-EOS5 files are read into file variables that use NetCDF-like conventions.

Non-alphanumeric characters in HDF-EOS5 variable names are replaced with the '_' character when listed from NCL and are referenced from NCL in this fashion. Note that due to the hierarchical structure of HDF files, variables with the same name can appear in different groups. Since NCL's NetCDF-like interface flattens this hierarchy, it appends the group name, preceded by an underscore, to all variable names in order to ensure that each variable name is unique within the context of the NCL file variable.

CCM - Community Climate Model History Tape Format

The CCM format is a format, originally in CRAY COS blocked form, written by the NCAR CCM1, CCM2, and CCM3 global climate models. It is also possible to have IEEE CCM files. Currently, NCL does not support IEEE CCM files due to lack of documentation. It is possible to use the public domain tool called "ccm2nc" (available on almost all SCD computers; "man ccm2nc") to convert these files to NetCDF. NCL can then reference the NetCDF file(s). If not on SCD machines then the "ccm2nc" software can be downloaded from http://ftp.cgd.ucar.edu/cms/ccm3/tools/

CCM files are pretty straightforward (no special naming convention is needed as with GRIB files); the variable names and unit information are stored as character data in the CCM files. When a CCM file is opened, NCL scans the file and creates an index of all the data in the files. This can be expensive for large files, but it facilitates quickly accessing individual variables of the file. Because this can be expensive, you should avoid repeatedly calling addfile on the same file whenever possible.

For more information on the CCM model and CCM file format, see the CCM3 User's Guide.

GRIB - Gridded Binary (version 1) or General Regularly-distributed Information in Binary Form (version 2)

(GRIB2 support available in versions 4.3.0 or later. )

Online documentation for GRIB is available at:

GRIB1
http://www.nco.ncep.noaa.gov/pmb/docs/on388/
GRIB2
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc.shtml.

NCL provides read-only support for data in GRIB1 and GRIB2 formats. To open a file, you only need to know that the file is GRIB. NCL figures out which version of GRIB is in the file and processes the file accordingly. NCL's support for GRIB is an evolving process. As an ever more diverse set of GRIB files have been encountered, NCL has been improved to handle many more features of the GRIB format. However, since GRIB has many features that are obscure enough that they have never been encountered in practice by the NCL developers, there are still some aspects of GRIB that NCL does not handle properly. Generally, the NCL developers try to support features that appear in GRIB files that users are actually using. The best way to help improve the GRIB-decoding capabilities of NCL is to call attention to files that are important to your work but that NCL does not seem to interpret correctly. If you have problems reading a particular set of GRIB files, please send email to ncl-talk@ucar.edu. You will need to subscribe first, if you haven't already.

At some point NCL may provide the ability to write GRIB, but, for now, the NCL developers consider their mission is to provide read access to as many types of GRIB files as possible.

GRIB is a compact file format composed of a series of independent records each generally containing a grid of data points covering some geographical extent. Each record contains in a coded form the information required to derive the location of the data points in space and time, the type of quantity the data represents, and the origin of the data, including who produced it and the generating model. But in order to decode the data, external information is required. This much is true both for GRIB1 and GRIB2. But while decoders for GRIB1 or for GRIB2 both rely on information from external tables and many of the individual pieces of information in the tables are the same, the organization of the tables is quite different. As the newer format, GRIB2 has the capability to allow for much more diversity of data without the need for the local extensions that have evolved over the years out of necessity in GRIB1. Also in spite of the evidence of some initial divergence there is hope at least that the GRIB 2 tables will become standardized enough that one set of tables can be used to decode GRIB files from anywhere in the world.

Before discussing the specifics of NCL's treatment of each format, it is worth looking at the common features. These arise partly from basic similarities in the formats, but also significantly from NCL's unifying data model.

Dimensions in GRIB

The fundamental thing that NCL does for both GRIB1 and GRIB2 is to assemble related records into NetCDF-like variables with named dimensions and coordinate variables. The right-most dimensions (usually two) are specified by the grid associated with each individual record. The naming conventions for the dimensions and coordinate variables vary somewhat between GRIB versions and are discussed in the version-specific details below. Dimensions to the left of the grid dimensions result from sorting the related records into a coherent order. These dimensions, in order from left to right (slowest to fastest varying) are:
  • ensemble or probability (4.3.0 or later.)
  • initial_time
  • forecast_time
  • level
Of course, variables in GRIB files seldom have all possible dimensions present. If the variable does not belong to an ensemble or probability sequence forecast, this dimension will be absent. If all the records have the same initial time then the initial time is by default presented as an attribute of the variable. This is likewise true for forecast time and level. Note, however, that as of version 4.3.0 or later, it is possible to tell NCL to convert any or all of these attributes into single element dimensions using an option to the setfileoption procedure called "SingleElementDimensions". This option is intended to simplify the concatenation of conforming variables from multiple files.

Generally these dimensions have associated one-dimensional coordinate variables. Following standard NetCDF conventions the coordinate variables have the same name as the dimensions. These variables have long names, types, and units that conform as much as possible to standard CF conventions. However, there are details peculiar to each of these dimensions that need discussion:

ensemble
The ensemble dimension uses an index variable as its coordinate variable. This variable simply serves to give a numeric ordering to the ensemble members. Otherwise, there is not always an easily-defined order to these elements. An auxiliary variable, implemented as an array of strings, gives information about each ensemble member.
probability
The probability dimension has as its coordinate variable an ascending series of threshold values of the quantity who probability is measured. Note that the variable itself contains percentage values indicating the likelihood of the quantity at each coordinate value. Note that, currently, NCL allows for only one of the ensemble or probability dimensions for any single variable. If this becomes a problem, it may change with future releases.
initial_time
As of version 4.3.0 or later the initial_time coordinate is expressed in a CF-compliant form as the number of hours since Jan 1, 1800. Prior to this release, it was by default an array of strings giving the date and time in a printable form. However, because string arrays do not have (in NCL, at least) the property of monotonicity, this type of coordinate variable was awkward for visualization purposes, and therefore it was changed. However, an option to the setfileoption procedure called "InitialTimeCoordinateType" allows you to revert to NCL's former behavior regarding the initial_time coordinate. Also, regardless of the type of the initial_time coordinate variable, NCL always supplies three representations of this information:
  • number of hours since Jan 1, 1800 (double type)
  • string array representation of date and time
  • an encoded representation of the date of type double, with units yyyymmddhh.hh_frac indicating the position and number of digits for the year, month, day, hour, and fractional part of the hour.
forecast_time
The forecast_time dimension is an integer offset from the initial_time. Its units are usually, but not always, hours.
levels
If GRIB records for a quantity exist at multiple vertical levels, NCL creates a level dimension for the variable. Depending on the level type, GRIB may specify a single level value, or it may specify the lower and upper bounds of the level. If the quantity is defined using a single value for each level, these values are incorporated into a normal coordinate variable. However, if the quantity is defined using the lower and upper bounds of the level, a standard coordinate variable (a one-dimensional variable with the same name as the dimension) cannot be used. Instead two auxiliary variables are supplied that are named by adding the suffixes "_l0" for the lower bounding level and "_l1" for the upper bounding level to the name of the dimension. NCL uses another scheme to represent GRIB hybrid level types. However, since hybrid levels are currently supported only for GRIB1, the particulars of this scheme are described below in the GRIB1 specific section.

GRIB Grids

NCL supports most of the same grid types in both versions of GRIB. Grids that are fully supported, with one exception, supply one or two dimensional coordinate variables that can be used to locate each point of the grid in latitude and longitude. For other grids, NCL still makes the data available as long as it can figure out the dimension sizes of the data. However, these grids provide no coordinate variables and NCL issues a warning noting that the support for the grid type is incomplete.

Grids with one-dimensional coordinates follow the standard NetCDF convention where the name of the dimension and the name of the coordinate variable are the same. These grids include:

  • Latitude/Longitude (also known as Cylindrical Equidistant or Plate Carree)
  • Mercator
  • Gaussian Latitude/Longitude
Latitude/Longitude and Gaussian Latitude/Longitude grids may be encoded in a "thinned" ("quasi-regular" in the GRIB documentation) format. These grids are progressively thinned, generally along the longitudinal dimension, as the latitude coordinates approach the poles, thus maintaining a more or less uniform distance between grid points as the circles around each latitude become shorter. NCL automatically interpolates such grids to standard rectangular grids, building normal 1D coordinate variables for them in the process. This process is transparent to the user except that the coordinate attributes specify that the grid is "quasi-regular". By default (as of version 4.3.0), a cubic interpolation algorithm is used because it has been determined to be the most accurate. However, the NCL procedure setfileoption has an option called "ThinnedGridInterpolation" which allows you to use a linear interpolation instead. The linear interpolation is also forced in cases where a bit-mask is used to omit some of the grid points.

Variables with grids that require two-dimensional coordinates use the CF-conforming attribute coordinates to list the names of the two associated two-dimensional coordinate variables. These two variables give the latitude and longitude respectively of each point in the grid. These variables also provide attributes that give sufficient information to generate a "native" map projection that exactly conforms to the projection parameters of the data. In addition, an auxiliary rotation variable gives the rotation angle that needs to be applied to vector data at each grid point to convert between grid-based angles and earth-based angles. Since in most cases the vector data angles are supplied relative to the grid, you would generally need to perform this operation in order to visualize vector data in projections other than the native projection. The formulas for converting the rotation angle are given in attributes of the rotation variable. The supported grids of this type are:

  • Rotated Latitude/Longitude
  • Polar Stereographic
  • Lambert Conformal
NCL also supports grids of Spherical Harmonic Coefficients. These are unique in that NCL separates the real and imaginary components into a third grid dimension called "real_imaginary". As supplied, the x and y axis do not have geographic meaning. In order to convert such a grid to a Latitude/Longitude or Gaussian grid it is necessary to process the data through an appropriate function.

Note: the GRIB1 reader also supports the following three specialized versions of Rotated Latitude/Longitude Grids:

  • Arakawa Semi-Staggered E-Grid
  • Arakawa Filled E-Grid
  • Arakawa Staggered E-Grid
Information specific to these grids is covered in the "GRIB1 Support Details" section below

GRIB1 Support Details

As of version 4.3.0 NCL can read GRIB1 files of basically unlimited size on any operating system that supports 64-bit file offsets.

GRIB1 relies on parameter tables to match a specific octet (byte) in the GRIB record to a particular parameter name. These tables have proliferated over the years because each center uses different models and produces different quantities for analysis. The WMO mandates a single standard parameter table for table entries 1 - 127, but any originating center can legitimately define its own tables for entries 128 - 255. Furthermore, in spite of the supposed mandate, important centers such as ECMWF define their own values for the lower-numbered entries as well. Additionally the GRIB specification allows a single center, such as ECMWF, to define multiple parameter tables each specialized for different kinds of data. These are distinguished using another octet called the "parameter table version".

Since there is no central repository of GRIB parameter tables and the originating centers span the globe, it is not realistic for a single GRIB reading tool to have access to all the tables needed to parse every GRIB file; or, even assuming the necessary tables are available, to be able to decide in every case which table applies to a particular GRIB record. Consequently, NCL's approach is to provide built-in access to a set of parameter tables that are considered to be generally reliable, but, in addition, to allow the user to supply their own parameter tables locally as text files. Because the user-supplied tables take precedence over the built-in tables, the user ultimately controls which parameter table applies to a particular GRIB file. More detailed information about the parameter tables appears at the end of this document in the sections Built-in GRIB1 parameter tables and User-defined GRIB1 parameter tables.

Since GRIB files usually have records with same parameter on different grids and different level types, using various time range indicators, NCL has introduced naming conventions that encode these distinctions to help ensure unique variable names. For example, consider the variable TMP (temperature). One GRIB file may contain the variable with many different variations. Some records might represent average temperature, others temperature differences from one time to the next, and yet others the temperature at tropopause. Clearly, these need to be treated as different variables in the file, but GRIB gives them all the parameter number corresponding to TMP.

The following section gives the algorithm NCL uses to assign names to GRIB1 variables.

GRIB1 data variable name encoding

    (Note: examples show intermediate steps in the formation of the name)

    if entry matching parameter table version and parameter number is found 
              (either in built-in or user-supplied table) and entry contains a short name for the parameter:
       if recognized as probability product:
          <probability_parameter_short_name>_<subject_variable_short_name> (ex: PROB_A_PCP) 
       else:
          <parameter_short_name> (ex: TMP) 
    else:
       VAR_<parameter_number> (ex: VAR_179)

    if pre-defined grid:
       _<pre-defined_grid_number> (ex: TMP_6)
    else if grid defined in GDS (Grid Description Section):
       _GDS<grid_type_number> (ex: TMP_GDS4)

    _<level_type_abbreviation> (ex: TMP_GDS4_ISBL)

    if not statistically processed variable and not duplicate name the name is complete at this point.

    if statistically-processed variable with constant specified statistical processing duration:
          _<statistical_processing_type_abbreviation><statistical_processing_duration><duration_units> (ex: ACPCP_44_SFC_acc6h) 
    else if statistically-processed variable with no specified processing duration
       _<statistical_processing_type_abbreviation> (ex: A_PCP_192_SFC_acc)

    if variable name is duplicate of existing variable name (this should not normally occur):
       _n (where n begins with 1 for first duplicate) (ex: TMP_GDS4_ISBL_1)
Notes:
  • Probability products are properly recognized in version 4.3.0 or later.
  • NCL uses the generic construction VAR_<parameter_number> in two situations:
    • The entry in the applicable published table contains no short name suitable for use as a component of an NCL variable name. Users should expect that later revisions to the table may result in the parameter receiving a short name, causing the name to change.
    • There is no recognized entry for the parameter number. In this case, NCL outputs a warning message. The parameter index could be unrecognized for several reasons:
      • No parameter table has been supplied for the originating center and the index is greater than 127. (The default GRIB parameter table properly applies only to indexes less than 128.)
      • The index is not present in the applicable parameter table, perhaps because the table is out of date or is otherwise incorrect.
      • The GRIB file has been generated incorrectly, perhaps specifying a wrong parameter table or a non-existent index.
  • Pre-defined grids are enumerated in Table B of the NCEP GRIB1 documentation.
  • GDS Grids types are listed in Table 6 of the NCEP GRIB1 documentation.
  • Level type abbreviations are taken from Table 3 of the NCEP GRIB1 documentation.
  • The abbreviations corresponding to the supported statistical processing methods are:
    • ave - average
    • acc - accumulation
    • dif - difference
    Note that the duration period and units abbreviation were added in NCL version 4.2.0.a028 in order to handle GRIB files with more than one time duration for otherwise identical variables. This is an unavoidable incompatibility for GRIB file variable names relative to earlier versions.

GRIB1 dimensions, coordinate, and auxiliary variables

In order to ensure the uniqueness of dimension and coordinate variable names, NCL assigns each GRIB1 dimension a unique number when it is first recognized. This number is usually appended to the end of the name.

GRIB1 grids
A single GRIB record generally contains data on a two-dimensional horizontal grid locating variables on the surface of the globe. This grid forms the two rightmost (occasionally three rightmost) dimensions of an NCL GRIB variable.

GRIB1 has two systems for defining these horizontal grids. There is a set of "pre-defined" grids that are indexed by a single octet (byte) in the GRIB record. These are completely specified as to the type of projection, number of grid points, and extent. Since these are by definition unique, dimensions and coordinates that specify these grids do not use the dimension number in their names. The other system uses the GDS (Grid Description Section) to assign a general grid type (e.g Lambert Conformal) and to specify the projection parameters and number of grid points. In this case, the grid type is not sufficient to uniquely specify the grid and therefore the unique dimension number is appended to the dimensions and coordinate variables.

The grid dimensions, coordinate variables, and associated auxiliary rotation variables are named as follows: 

if grid is pre-defined and has single-dimensioned coordinates:
    dimensions and coordinates:  
       lat_<pre-defined_grid_number>, lon_<pre-defined_grid_number> (ex: lat_30, lon_30)
else if grid is pre-defined:
    dimensions:
       gridx_<pre-defined_grid_number>, gridy_<pre-defined_grid_number> (ex: gridx_6, gridy_6)
    coordinates:
       gridlat_<pre-defined_grid_number>, gridlon_<pre-defined_grid_number> (ex: gridlat_6, gridlon_6)
    auxiliary rotation variable:
       gridrot_<pre-defined_grid_number> (ex: gridrot_6)
else if GDS grid has single-dimensioned coordinates:
    dimensions and coordinates:  
       g<grid_type_number>_lat_<dimension_number>, g<grid_type_number>_lon_<dimension_number> (ex: g0_lat_7, g0_lon_8)
else if GDS grid type is 50 (Spherical Harmonic Coefficients)
    dimensions: 
       real_imaginary, g50_lat_<dimension_number>, g50_lon_<dimension_number> (ex: real_imaginary, g50_lat_1, g50_lon_2)
else if GDS grid type is 203 (Arakawa semi-staggered E-Grid)
    mass dimensions: 
       g203m_x_<dimension_number>, g203m_y_<dimension_number> (ex: g203m_x_0, g203m_y_1)
    mass coordinates:
       g203m_lat_<dimension_number>, g203m_lon_<dimension_number> (ex: g203m_lat_0, g203m_lon_1)
    velocity dimensions: 
       g203v_x_<dimension_number>, g203v_y_<dimension_number> (ex: g203v_x_5, g203v_y_6)
    velocity coordinates:
       g203v_lat_<dimension_number>, g203v_lon_<dimension_number> (ex: g203v_lat_5, g203m_lon_6)
else (other GDS grid):
    dimensions: 
       g<grid_type_number>_x_<dimension_number>, g<grid_type_number>_y_<dimension_number> (ex: g10_x_5, g10_y_6)
    coordinates:
       g<grid_type_number>_lat_<dimension_number>, g<grid_type_number>_lon_<dimension_number> (ex: g10_lat_5, g10_lon_6)
   auxiliary rotation variable:
       g<grid_type_number>_rot_<dimension_number> (ex: g10_rot_6)
Notes:
  • The dimensions of two-dimensional coordinates have the dimension labelled 'y' as the right-most (fastest-varying) dimension. NCL's GRIB2 reader changed this convention to use 'x' as the indicator of the right-most dimension. The change was intended to be more in accord with the GRIB documentation as well as with conventional usage.
  • Grids of spherical harmonic coefficients have an additional 2-element dimension called "real_imaginary". However, they do not supply coordinate variables. Also although the dimensions have "lat" and "lon" in the names the data cannot be placed on any kind of lat/lon grid without transforming the data through an appropriate function.
  • The Arakawa semi-staggered E-grid has two grids, each offset slightly from the other. One grid locates the "mass" data points, the other the "velocity" points. NCL assigns the velocity grid to variables that it believes are of vector type. However, if this assignment seems incorrect, users can freely decide to use either grid for any variable as they think appropriate.
GRIB1 levels
If a variable exists on more than one vertical level, it will have a level dimension. As stated earlier, depending on level type, a level may be specified as a single value, or using two bounding values. For hybrid level types, each GRIB record encodes the coefficients required to convert the hybrid levels into pressure level values. These appear as auxiliary variables. The actual level coordinate in this case is just an integer index. However it specifies how to compute the pressure levels using the CF-compliant attribute formula_terms. The naming scheme for level dimensions, coordinates, and auxiliary variables is as follows: 
if single level value:
    if level type is not hybrid level:
       dimensions and coordinates:  
           lv_<level_type_abbreviation><dimension_number> (ex: lv_ISBL7)
    else:
       if hybrid coefficients given at level midpoints -- DWD convention:
           dimensions and coordinates:
               lv_HYBL<dimension_number> (ex: lv_HYBL9)
           auxiliary hybrid vertical coordinates (includes scalar parameterization values as attributes):
               lv_HYBL<dimension_number>_vc (ex: lv_HYBL9_vc) 
       else if hybrid coefficients given at level midpoints:
           dimensions and coordinates:
               lv_HYBL<dimension_number> (ex: lv_HYBL0)
           auxiliary hybrid A coefficient:
               lv_HYBL<dimension_number>_a (ex: lv_HYBL0_a) 
           auxiliary hybrid B coefficient:
               lv_HYBL<dimension_number>_b (ex: lv_HYBL0_b)
           auxiliary scalar reference pressure:
               P0
       else if hybrid coefficient given at level boundaries:
           dimensions and coordinates:
               lv_HYBL<dimension_number> (ex: lv_HYBL0)
           auxiliary boundary interface dimension (sized one greater than number of levels):
               lv_HYBL_i<dimension_number> (ex: lv_HYBL_i1)
           auxiliary hybrid A boundary interface coefficient:
               lv_HYBL_i<dimension_number>_a (ex: lv_HYBL_i1_a) 
           auxiliary hybrid B boundary interface coefficient:
               lv_HYBL_i<dimension_number>_b (ex: lv_HYBL_i1_b)
           auxiliary hybrid a coefficient (derived as average of adjacent interface coefficients):
               lv_HYBL<dimension_number>_a (ex: lv_HYBL0_a) 
           auxiliary hybrid b coefficient (derived as average of adjacent interface coefficients):
               lv_HYBL<dimension_number>_b (ex: lv_HYBL0_b)
           auxiliary scalar reference pressure:
               P0
else (if lower and upper boundary level values):
    dimensions:
        lv_<level_type_abbreviation><dimension_number> (ex: lv_DBLY8)
    auxiliary lower boundary level values:                 
        lv_<level_type_abbreviation><dimension_number>_l0 (ex: lv_DBLY8_l0)
    auxiliary upper boundary level values:                 
        lv_<level_type_abbreviation><dimension_number>_l1 (ex: lv_DBLY8_l1)
Notes:
GRIB1 forecast_time
The forecast_time dimension is handled in a very straightforward way in GRIB1. The dimension and coordinate names are derived as follows: 
dimensions and coordinates:  
   forecast_time<dimension_number> (ex: forecast_time3)
Notes:
  • Versions of NCL prior to 4.3.0 may incorrectly specify the forecast_time units as hours when they are not. These same previous versions of NCL do not properly handle GRIB files with forecast_time units that vary for a single variable.
GRIB1 initial_time
Version 4.3.0 changed the default type of the initial_time coordinate dimension from an array of strings to an array of doubles with units of "hours since 1800-01-01 00:00". As noted earlier, you can revert to the earlier behavior using the setfileoption procedure option called "InitialTimeCoordinateType". Dimensions, coordinates, and associated auxiliary variables are named as follows: 
if setfileoption option "InitialTimeCoordinateType" is set to "Numeric" (default):
   dimensions and coordinates (units of hours since 1800-01-01 00:00):  
      initial_time<dimension_number>_hours (ex: initial_time0_hours)
   auxiliary string representation:
      initial_time<dimension_number> (ex: initial_time0)
   auxiliary encoded double representation (units of yyyymmddhh.hh_frac):
      initial_time<dimension_number>_encoded (ex: initial_time0_encoded)
else (if setfileoption option "InitialTimeCoordinateType" is set to "String":
   dimensions and coordinates:  
      initial_time<dimension_number> (ex: initial_time0)
   auxiliary numeric representation (units of hours since 1800-01-01 00:00):
      initial_time<dimension_number> (ex: initial_time0)
   auxiliary encoded double representation (units of yyyymmddhh.hh_frac):
      initial_time<dimension_number>_encoded (ex: initial_time0_encoded)
GRIB1 ensemble
The ensemble dimension coordinate variable is a simple integer index. It has an auxiliary variable that explains the significance of each element in the ensemble dimension: 
dimensions and coordinates:  
   ensemble<dimension_number> (ex: ensemble2)
auxiliary informational string array:
   ensemble<dimension_number>_info (ex: ensemble2_info)
GRIB1 probability
The probability dimension coordinate variable is composed of the values representing threshold values of the quantity whose probability is under consideration. 
dimensions and coordinates:  
   probability<dimension_number> (ex: probability4)

GRIB2 Support Details

Available in version 4.3.0 and later.

NCL uses the GRIB2 g2clib encoder/decoder library from NCEP to perform the low-level decoding of GRIB2 files. Since this library is limited to processing files that are less than 2 GB in size, NCL only supports reading GRIB2 files of 2 GB or less.

NCL distinguishes records that need to be classified into separate variables based on differences in the following characteristics:

  • originating center
  • sub-center
  • production status
  • type of processed data
  • significance of the reference (initial) time
  • product definition template number
  • product discipline
  • parameter category
  • parameter number
  • type of statistical processing
  • statistical processing duration
  • first fixed surface (level) type
  • second fixed surface (level) type
  • probability type
  • grid definition template number
  • grid parameters (contents of grid template)
The GRIB2 documentation provides more information about these characteristics. You may notice that they are selected from different sections of the GRIB2 record structure. Some, such as "type of statistical processing", are only applicable when the "product definition template number" has certain values. Generally speaking all of the applicable characteristics must be the same for two records to be considered part of the same variable. NCL uses a different set of characteristics to sort the records into a coherent variable with ordered dimensions.

NCL forms a name for each unique variable it discovers based on the characteristics that usually vary within a file. Some characteristics, such as the originating center, are normally constant for all the records in a single GRIB file (or for that matter in set of conforming files) and therefore are not encoded into the name. Most of the information required to establish the name is contained the GRIB2 code tables that are supplied with NCL. In particular the initial prefix (the "short name") of the variable is determined by looking up three characteristics: product discipline, parameter category, and parameter number. Files produced for the TIGGE project use a slightly different scheme that involves considering other characteristics, such as the type of statistical processing, to determine the initial prefix for the variable. Because this scheme is more complex, a table embedded in the source code is currently used to determine TIGGE name prefixes. Unlike the tables supplied by NCEP, TIGGE prefixes are conventionally in lower case. The following section gives the algorithm for encoding data variable names in GRIB2.

GRIB2 data variable name encoding

    (Note: examples show intermediate steps in the formation of the name)

    if production status is TIGGE test or operational and matches entry in TIGGE table:
       <parameter_short_name> (ex: t) 
    else if entry matching product discipline, parameter category, and parameter number is found:
       <parameter_short_name> (ex: TMP) 
    else:
       VAR_<product_discipline_number>_<parameter_category_number>_<parameter_number> (ex: VAR_3_0_9)

    _P<product_definition_template_number> (ex: TMP_P0)

    if single level type:
       _L<level_type_number> (ex: TMP_P0_L103)
    else if two levels of the same type: 
       _2L<level_type_number> (ex: TMP_P0_2L106)
    else if two levels of different types: 
       _2L<_first_level_type_number>_<second_level_type_number> (ex: LCLD_P0_2L212_213)

    if grid type is supported (fully or partially):
       _G<grid_abbreviation><grid_number> (ex: UGRD_P0_L108_GLC0)
    else:
       _G<grid_number> (ex: UGRD_P0_2L104_G0)

    if not statistically processed variable and not duplicate name the name is complete at this point.

    if statistically-processed variable and constant statistical processing duration:
       if statistical processing type is defined:
          _<statistical_processing_type_abbreviation><statistical_processing_duration><duration_units> (ex: APCP_P8_L1_GLL0_acc3h) 
       else
          _<statistical_processing_duration><duration_units> (ex: TMAX_P8_L103_GCA0_6h)
    else if statistically-processed variable and variable-duration processing always begins at initial time:
       _<statistical_processing_type_abbreviation> (ex: ssr_P11_GCA0_acc)

    if variable name is duplicate of existing variable name (this should not normally occur):
       _n (where n begins with 1 for first duplicate) (ex: TMAX_P8_L103_GCA0_6h_1)
The fully or partially supported grid type abbreviations are:
  • LL - Latitude/Longitude
  • RLL - Rotated Latitude/Longitude
  • ME - Mercator
  • ST - Polar Stereographic
  • LC - Lambert Conformal
  • GA - Gaussian Latitude/Longitude
  • SH - Spherical Harmonic Coefficients
  • SV - Space View Perspective or Orthographic (partial support)
The statistical processing type abbreviations are:
  • avg - average
  • acc - accumulation
  • max - maximum
  • min - minimum
  • dife - difference (end - beginning)
  • rms - root mean square
  • std - standard deviation
  • cov - covariance
  • difb - difference (beginning - end)
  • rat - ratio

GRIB2 dimensions, coordinate, and auxiliary variables

NCL's GRIB2 reader uses a slightly different scheme than the GRIB1 reader to ensure the uniqueness of dimension and coordinate variable names. Whereas the GRIB1 reader maintains a single count and numbering system for dimensions of all types, the GRIB2 reader numbers each dimension type separately. For example, in GRIB1 the name forecast_time2 means the third (since the count starts with 0) unique dimension of any sort encountered while processing a file, but in GRIB2 this same name means the third unique dimension of type forecast_time.
GRIB2 grids
Unlike GRIB1, GRIB2 uses only one system, a "Grid Description Template", for specifying the parameters of a grid. NCL uses a single grid number that is sequentially incremented as new grids are encountered to label all the dimensions and coordinate variables belonging to a particular grid. NCL also uses the same naming scheme for all GRIB2 grid types. This means that NCL's system of naming GRIB2 grid dimensions and variables is considerably simpler than the GRIB1 scheme. The grid dimensions, coordinate variables, and associated auxiliary rotation variables are named as follows: 
if grid has single-dimensioned coordinates:
    dimensions and coordinates:  
       lat_<grid_number>, lon_<grid_number> (ex: lat_4, lon_4)
else if grid type is Spherical Harmonic Coefficients:
    dimensions: 
       real_imaginary, lat_<grid_number>, lon_<grid_number> (ex: real_imaginary, lat_1, lon_1)
else (2D coordinates):
    dimensions: 
       ygrid_<grid_number>, xgrid_<grid_number> (ex: ygrid_4, xgrid_4)
    coordinates:
       gridlat_<grid_number>, gridlon_<grid_number> (ex: gridlat_4, gridlon_4)
    auxiliary rotation variable:
       gridrot_<grid_number> (ex: gridrot_4)
Notes:
  • GRIB1 uses the label 'y' as a designator for the right-most (fastest-varying) dimension of grids with 2D coordinates. NCL's GRIB2 reader changes this convention to use 'x' as the indicator of the right-most dimension. The change is intended to be more in accord with the GRIB documentation as well as with conventional usage.
  • Grids of spherical harmonic coefficients have an additional 2-element dimension called "real_imaginary". However, they do not supply coordinate variables. Also although the dimensions have "lat" and "lon" in the names the data cannot be placed on any kind of lat/lon grid without transforming the data through an appropriate function.
GRIB2 levels
GRIB2 level dimensions and coordinates have names that are very similar to GRIB1 level names. One difference is that no auxiliary variables are currently supplied for hybrid levels. As with GRIB1, depending on level type, a level may be specified as a single value, or using two bounding values. The naming scheme for level dimensions, coordinates, and auxiliary variables is as follows: 
if single level value:
    dimensions and coordinates:  
       lv_<level_type_abbreviation><level_dimension_number> (ex: lv_ISBL7)
    else:
else (if lower and upper boundary level values):
    dimensions:
        lv_<level_type_abbreviation><level_dimension_number> (ex: lv_DBLY8)
    auxiliary lower boundary level values:                 
        lv_<level_type_abbreviation><level_dimension_number>_l0 (ex: lv_DBLY8_l0)
    auxiliary upper boundary level values:                 
        lv_<level_type_abbreviation><level_dimension_number>_l1 (ex: lv_DBLY8_l1)
Notes:
GRIB2 forecast_time, initial_time, ensemble, and probability
The remaining GRIB2 dimensions and coordinate variables are handled exactly like the corresponding GRIB1 dimensions and coordinate variables, except that each dimension type is separately counted and numbered. Refer to the corresponding GRIB1 sections for details:

GRIB2 backwards incompatibility alert

In version 5.2.0, the GRIB2 code tables were extensively revised to bring them up-to-date with the currently documented state of the parameter tables primarily as defined by NCEP in links from the parameter category page at http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-1.shtml. ECMWF tables, as documented at http://www.ecmwf.int/publications/manuals/d/gribapi/fm92/grib2/show/parameter/, were also consulted with the goal of harmonizing the parameter lists and descriptions as much as possible. The number of defined parameter has almost doubled, increasing from 371 to 701. This should eliminate most of the warnings about unrecognized parameters. Unfortunately, this process has led to some unavoidable backwards incompatibilities, primarily due to changes in the short names that form the base name for NCL variables that represent the aggregated GRIB records.

When GRIB2 was first introduced the NCEP documentation did not include abbreviations (short names) for many parameters. Since NCL's variable naming scheme requires a short name, NCL developers invented them where needed. Now, however, NCEP has created their own abbreviations for every parameter. Naturally enough, these names do not all coincide with the short names chosen by the NCL developers. To prevent confusion and to promote future interoperability, the NCL development team has decided that the importance of using essentially the same parameter names as NCEP outweighs the immediate cost of a certain amount of backwards incompatibility. As a gauge of the scope of the problem, 92 short names (approximately 25% of the parameter total prior to this release) have had short name changes. However, this statistic may exaggerate the scope of the problem, because many or most of these changes apply to new and therefore probably relatively obscure parameters.

In order to mitigate this problem for users who may not immediately be able to update their codes to reflect the new variable names, the previous version of the code tables is being included with the distribution in a parallel directory tree. Users can switch from the default set of code tables located at $NCARG_ROOT/lib/ncarg/grib2_codetables by setting the environment variable NIO_GRIB2_CODETABLES to point to $NCARG_ROOT/lib/ncarg/grib2_codetables.previous. For reference a list of the short name changes and additions is available here.

There have also been some changes to the parameter description string that serves as the value of the long_name attribute. Basically the capitalization as been regularized by making all words except the initial word lower case. The only exception to this rule is for acronyms that are traditionally all upper-case.

Note that the GRIB2 codetables are text files that can easily be edited. Therefore users who do not like any aspect of the presentation of the parameters can create their own copy of the directory tree and modify it to suit their needs. By pointing NIO_GRIB2_CODETABLES to this copy of the code tables NCL will immediately incorporate the modifications into its presentation of GRIB2 data.

One additional point is that sort of incompatibility should not happen again. The new NCL development policy is that short names will no longer be invented. If parameters happen to be documented without an abbreviation, they will appear in NCL's presentation of the data as VAR_x_x_x_... (for GRIB2 data), where the 3 'x's stands for discipline, category, and parameter number. This is also true for GRIB1 data, except that the form is VAR_x_..., where 'x' is simply the parameter number.

Built-in GRIB1 parameter tables

NCL's built-in parameter tables have been assembled from a number of sources. A prominent acknowledgement must go to the freely available wgrib program (http://wesley.wwb.noaa.gov/wgrib.html). The ECMWF tables are available at http://www.ecmwf.int/publications/manuals/libraries/tables/tables_index.html. The FSL tables were obtained from private contacts at NOAA's Forecast Systems Laboratory in Boulder. Thanks also to Wenchieh Yen of the Institut fuer Physick der Atmosphere who provided recent new and updated table versions for DWD. Here is a list of the supported tables with links to their contents: The first table in this list, the NMC operational table, contains the WMO standard entries described in the GRIB documentation (http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html). Since the parameters less than 128 are mandated by the GRIB documents, they are used by default when NCL cannot otherwise determine an applicable parameter table. Note, however, that user-defined parameter tables must include these parameters even if they match the standard table. NCL does not default to the standard table for any unfound indexes if it has found a suitable user-defined parameter table.

User-defined GRIB1 parameter tables

An NCL GRIB parameter table file is a text file that specifies one or more distinct parameter tables for NCL to use when reading GRIB files. Setting the environment variable NCL_GRIB_PTABLE_PATH to the pathname of the file causes NCL to parse it and incorporate its parameter tables when first asked to open a GRIB file. Optionally, NCL_GRIB_PTABLE_PATH may be set to a directory path, in which case all files in the directory with the suffix '.gtb' are opened as parameter tables.

A line beginning with a '!' (optionally preceded by whitespace) is a comment. The separator string is adjustable: it may be set to any non-alphanumeric, non-whitespace character, or it may simply be two spaces in a row. It is determined from what follows immediately after the first table header row signal index (-1). Any amount of whitespace may surround the separator string. There is no way to escape the separator string, so it must be set to something that is not used in any of the informational fields.

The table header row consists of the signal index (-1) followed by 3 required fields: center, subcenter, and parameter table version. The parameter table that follows will be used for any GRIB record whose center, subcenter, and table version matches what is specified in the table header row, overriding any built-in parameter tables that would otherwise match. Setting any of these fields to '-1' results in an automatic match. If you set all three fields to '-1' the table will be used for all GRIB files. If two or more tables would equally match for a particular GRIB record, it is undefined which will be used.

Parameter rows consist of the parameter index followed by an abbreviation suitable for use as an NCL file variable, then a string representing units, and finally the longname (a short description of the variable). The abbreviation must contain only alphanumeric characters and/or the underscore character. Index values that are not defined need not be included.

Here is a sample portion of a valid parameter table file: 

-1 : 98 : 0 : 128 
018 : T : 	K : 	Temperature
019 : Z : 	m2/s2 : 	Surface geopotential
020 : GP : 	kg/s2 : 	Geopotential
021 : U_TE : 	J/ms : 	Total energy u-flux
022 : V_TE : 	J/ms : 	Total energy v-flux
081 : U_KE : 	J/ms : 	Kinetic energy u-flux
082 : V_KE : 	J/ms : 	Kinetic energy v-flux
The table header row indicates center 98, subcenter 0, parameter table version 128. From the list of originating centers at http://www.nco.ncep.noaa.gov/pmb/docs/on388/table0.html in the GRIB documentation, one can determine that this means the center is the European Center for Medium-Range Weather Forecasts - Reading or ECMWF, and in fact this is an alternate version of the standard ECMWF parameter table version 128, required to decode a specific GRIB dataset.

OGR - Open Geospatial Consortium's Simple Features formats (Shapefile, MapInfo, GMT, TIGER)

Online documentation for OGR is available at http://gdal.org/ogr/index.html.

With NCL 5.1.1, the optional GDAL/OGR library is used to read various OGR file formats. OGR is an implementation of the Open Geospatial Consortium's "Simple Features" API. The specific formats supported in NCL 5.1.1 are ESRI Shapefiles, MapInfo and GMT formats, and classic TIGER format. This is considered a beta-level capability.

Data in these formats are generally comprised of a set of files that together encode the geometry, non-spatial attributes, cartographic projection, indices, etc.. Although these formats are identified to NCL by the suffix of a specific file in the set, it is important that the complete set of files is available to NCL. For example, the suffix for Shapefiles is .shp; however a Shapefile properly consist of 4 or more commonly-named files with .dbf, .shx, .prj suffixes, in addition to the .shp file.

To the user, OGR data is viewed as a set of features that consist of geometry and other non-spatial fields. The non-spatial data in a given OGR file is mapped directly to an NCL variable. Non-spatial fields exist in a 1:1 relationship with features, so that the data for the ith feature is found at the ith elements of the NCL variables.

The geometry for a feature can be complex however; a feature might be comprised of one or more line segments, which in turn may represent polylines or polygons, etc. Because the relationship of geometry to features is not a simple 1:1 correspondence, the following convention has been adopted to encode geometry into specific NCL variables.

For each feature in the OGR file, there is an entry in an NCL variable named geometry. Each entry contains 2 items:

  • geometry(i, 0) = index into the segments variable of the first segment for the ith feature
  • geometry(i, 1) = the number of segments belonging to the ith feature

The NCL variable segments contains a partially ordered list of segments (individual points, polylines, polygons). There are one or more entries in this table per feature; geometry points to the first such segment of a feature, and any additional segments directly follow. Entries in segments in turn point to the actual xy(z) coordinates:

  • segments(j, 0) = index into x, y, z arrays of the first point of the jth segment
  • segments(j, 1) = number of points making up the jth segment

The coordinates of geometry are stored in the x, y, and optional z variables. These are one-dimensional arrays that contain partially ordered lists of coordinates that make up the individual segments.

Several global attributes are defined for convenience. The attribute layer_name contains the name of the features, as extracted from the OGR file. The attribute geometry_type denotes whether the feature-geometry is comprised of points, polylines, or polygons. The remaining attributes are intended as symbolic indices into the second index of the geometry and segments variables, and should be used in preference to hard coding indices; these are: geom_segIndex(=0), geom_numSegs(=1), segs_xyzIndex(=0), and segs_numPnts(=1). OGR file-variables do not contain coordinate variables or variable attributes, as the GDAL/OGR implementation does not expose information that could be used as such.

The following NCL excerpt illustrates how to draw geometry for features composed of polylines: 

  ...
  ; Loop over the feature-geometry in file-variable f, 
  ; drawing the line-segments associated with each one...
  ;
  dims = dimsizes(f->geometry)
  numFeatures = dims(0)
  segNum = 0
  do i=0, numFeatures-1
     startSegment = f->geometry(i, f@geom_segIndex)
     numSegments = f->geometry(i, f@geom_numSegs)
     do seg=startSegment, startSegment+numSegments-1
        startPT = f->segments(seg, f@segs_xyzIndex)
        endPT = startPT + f->segments(seg, f@segs_numPnts) - 1
        lines(segNum) = gsn_add_polyline(wks, plot, f->x(startPT:endPT), \
            f->y(startPT:endPT), plres)
        segNum = segNum + 1
     end do
  end do
  ...

Known Issues

  • Incomplete mapping of database types. For shapefiles in particular, certain types in the associated .dbf database do not have naturally analogous NCL types, e.g., timestamps, binary data, variable-length data, etc. In the present implementation, non-spatial fields of these types are disregarded and no corresponding NCL variable is created.
-