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.
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