[netCDF #JZN-949284]: NC_CHAR coordinates via DAP

Dennis,

I think the issue Charlie is concerned with is whether it's possible for
the DAP client to support a kind of netCDF coordinate variable in common
use, with character-array values coordinates.  A numeric coordinate,
such as "latitude", typically has single values of a primitive type,
such as float, and the values of a grid over Colorado might be 34.0,
35.0, ..., 43.0.  A string coordinate, such as "month", typically has
string values modeled as character arrays, such as "jan", "feb", ...,
"dec".

The use of such string-valued coordinates is discussed in the CF
Conventions, where they are also called "labels": 

  
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#labels

The netCDF Best Practices document has, in the section on coordinate
variables, this definition:

  A two-dimensional variable of type char is a string-valued coordinate
  variable if it has the same name as its first dimension, e.g.: char
  time( time, time_len); all of its strings must be unique.

Apparently NCO understands string-valued coordinate variables or
"labels" and treats them like other coordinate variables.

--Russ
  

> The netcdf dap code supports NC_CHAR (modulo bugs, of course).
> The transparency issue is tricky. If you mean does the result coming
> out of the netcdf dap code look the same as the original .nc file,
> then no. The two versions will vary in a number of ways because the mapping
> into dap and then out of dap is not completely transparent.
> 
> One place in particular where this occurs is when the dap uses its string typ
> e
> (look at this url in your browser
>   http://motherlode.ucar.edu:8080/thredds/dodsC/testdods/in.nc.dds?fl_dmn
> )
> 
> Since netcdf-3 has no string type, the string is converted to an NC_CHAR arra
> y.
> The string as stored in that array may be truncated.
> 
> There is an additional problem with the data set your provided.
> If you do a wget on this url:
>   http://motherlode.ucar.edu:8080/thredds/dodsC/testdods/in.nc.dods?fl_dmn
> you will get this:
> ------------------------------
> Dataset {
>     String fl_dmn[fl_dmn = 3];
> } testdods/in.nc;
> 
> Data:
> Error {
>     code = 500;
>     message = "[C cannot be cast to [Lopendap.dap.BaseType;";
> };
> ---------------------
> So indeed, the data is not readable. That error is coming from the server.
> Why that error occurs, I do not know yet.
> (Ethan?).
> 
> Other, non-string data is apparently readable.
> 
> =Dennis Heimbigner
>   Unidata
> 
> 
> Ticket Details
> ===================
> Ticket ID: JZN-949284
> Department: Support netCDF
> Priority: Normal
> Status: Open
> Link:  https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=vi
> ewticket&ticketid=12210



Ticket Details
===================
Ticket ID: JZN-949284
Department: Support netCDF
Priority: Normal
Status: Open