Greetings Jeffery, Let me see if I can address your questions. > Greetings, > > I am new to working with netCDF, and am using the Java API. > > I have some data sets from NCOM which I believe are the older pre-4 > format. The header is CDF 0x01, which I ran across somewhere as indicates > it is the older format. One way to check for sure is to use the utility ncdump utility: ncdump -k file.nc This will tell you specifically what kind of netCDF file you are dealing with. ncdump comes with the netCDF C package. > > I have some questions: > > * I read a great deal about using the standard name tables for naming > variables, yet the names used in the actual header do not match > these. The standard name tables most commonly used are the standard names in the Climate and Forecast (CF) standard. These names are applied as attributes to variables in the file, and need not have anything to do with the actual variable name itself. Standard names in CF are not used to completely identify a variable (they aren't intended to restrict the name space for variables), but more along the line of identifying the physical quantity contained within the variable. For example, the variables tmp_1 and tmp_2 could both have the same standard_name attribute of 'temperature', which would allow software to understand that these two variables could be directly comparable as temperature related quantities. The variable naming scheme is definitely bad in that example, but it shows how standard_name would link the two as containing variables with similar physical quantities. Now, if tmp_1 had a standard name attribute of temperature, and tmp_2 had a standard name attribute of wind_sp eed (in this case, the tmp in the var name might mean temporary), then software would have a way to see that these were not directly comparable variables (that is, without more context [like an equation], it does not make sense to add a field of temperature to a field of windspeed). > So will it just be a matter of trying different types of > requests to their data sets until I figure out if I have all the > variations correct? Was there another "standard" list of variable > names I missed in the copious documentation? Each different kind of dataset will likely have its own particular set of variable names (this is set by the data provider), and it's going to be up to the user to make the call as to which variable they are interested in manipulating. However, you can make a pass at checking for the standard name attributes using the Java API (see next comment). > > * The Java API calls don't have a way to ask for the standard name when > you get the header info. Is this going to happen? I did see where you > could ask for the "full" name, which turned out to be the shortened > name they were using for the variable. This was not even the long name, > nor the standard name. An example was when asking for latitude data, > the variable was named lat and the identified long name was Latitude > in the header. When you requested the "full" name, you got "lat". There > was not an attribute set for the standard name If you haven't checked out this page yet, it would be a good start: http://www.unidata.ucar.edu/software/netcdf/examples/programs/ Specifically, check out the java example under "Read data variables and attributes from the file written above:" section. This shows an example of how to read the attributes from variables contained within a netCDF dataset, which it sounds like is what you are really wanting to do. For example, this little code snippet tempVar.findAttributeIgnoreCase("units").getStringValue().equalsIgnoreCase("celsius") will find the attribute "units" (you would want to use standard_name), and checks to see if it is equal to "celsius" (all case insensitive). Note that tempVar comes from: Variable tempVar= dataFile.findVariable("temperature"); where the actual variable name (from the header) is "temperature". > > Are my above issues just a matter of the developers being ahead of the > deployed system, as is common here? > > The list of actual variable names being used would be a help. I am not aware of many data providers that explicitly constrain the variable name space - this is just something that will vary from data provider to data provider. The idea is that the metadata (attributes) attached to each variable is always going to be needed to fully understand what the variable is - the actual variable name simply cannot capture all of those details. Cheers, Sean > > Thanks, > > Jeffrey Noel Ethridge > Advisory Software Engineer > Undersea Systems > Northrop Grumman Corporation > PO Box 1488 MS 9035 > 895 Oceanic Drive > Annapolis MD 21408 > address@hidden > 410-260-5968 > > > > Greetings, > > I am new to working with netCDF, and am using the Java API. > > I have some data sets from NCOM which I believe are the older pre-4 > format. The header is CDF 0x01, which I ran across somewhere as indicates > it is the older format. > > I have some questions: > > * I read a great deal about using the standard name tables for naming > variables, yet the names used in the actual header do not match > these. So will it just be a matter of trying different types of > requests to their data sets until I figure out if I have all the > variations correct? Was there another "standard" list of variable > names I missed in the copious documentation? > > * The Java API calls don't have a way to ask for the standard name when > you get the header info. Is this going to happen? I did see where you > could ask for the "full" name, which turned out to be the shortened > name they were using for the variable. This was not even the long name, > nor the standard name. An example was when asking for latitude data, > the variable was named lat and the identified long name was Latitude > in the header. When you requested the "full" name, you got "lat". There > was not an attribute set for the standard name > > Are my above issues just a matter of the developers being ahead of the > deployed system, as is common here? > > The list of actual variable names being used would be a help. > > Thanks, > > Jeffrey Noel Ethridge > Advisory Software Engineer > Undersea Systems > Northrop Grumman Corporation > PO Box 1488 MS 9035 > 895 Oceanic Drive > Annapolis MD 21408 > address@hidden > 410-260-5968 > > > Ticket Details =================== Ticket ID: QDJ-886001 Department: Support netCDF Java Priority: High Status: Open
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.