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

[netCDFJava #SBZ-133456]: [netcdf-java] Bug report: Variable name must be unique within Group

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: [netCDFJava #SBZ-133456]: [netcdf-java] Bug report: Variable name must be unique within Group
  • Date: Tue, 20 Sep 2011 15:40:39 -0600
David- I am indeed sorry it took so long.
I kept thinking this was an ncml problem
and it was not.

> I believe the netcdf libraries use the opendap protocol to access remote 
> datasets, is this correct?
Yes, by default, most data is accessed using opendap.
The most recent version of tds supports (now) a new protocol
called cdmremote which properly handles groups. But I see in looking
at your catalog, that is option is not available to you.

>Are there not potential work around solutions to explore, within for 
>example ucar.nc2.Group class and its addVariable method?  At a minimum 
>perhaps a try catch could be used instead of throwing a new exception.

There are two short term solutions I can think of.
1. when duplicate variables are encountered, the second one
   is renamed to some unique name.
2. record the fact that there is a duplicate variable
   as an attribute
3. Use structs to simulate groups.

The best current solution is to do consistent renaming
of variables, dimensions, etc. to include the group path
as part of the name. This is on our list of tasks to do
(see https://www.unidata.ucar.edu/jira/browse/CDM-66).
I will bump the priority on this.

> As someone that relies on the netCDF library, I am surprised that 3 
> months after submitting this issue, the ticket is closed with a 
> recommendation to use a different protocol.
The issue is not closed for me. I want to see if we can find a usable quick fix
(well, 3 months makes any solution not quick). The "closed" state in our 
e-support
is just an artifact of e-support. The Jira issue is still open.

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: SBZ-133456
Department: Support netCDF Java
Priority: Critical
Status: Closed