NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Steve Emmerson wrote: > > I don't think you misinterpreted my original posting on creating a > quantity database. Tom's comment yesterday on (basically) dimensional > analysis was something of a tangent. I responded further along that > tangent by noting that the Unit classes already have partial support > for such stuff. My "quantity database", however, is orthogonal to > dimensional analysis. Currently, I view it as an customizable mapping > between names and MathTypes. For example, the following entries would > exist (interpret them imaginatively rather than rigorously): > > "energy" -> RealType("energy", "joules", FloatSet(, null, "joules")) > > "velocity" -> RealTupleType("velocity", "meters/second", > FloatSet(, null, {"m/s", "m/s", "m/s"})) > > Naturally, I'll have to handle the circular dependency between the > various MathTypes and their associated Sets. > > I envision a standard set of quantities coming with VisAD together with > the ability to create and add others. I'm currently thinking about > disallowing modifying the "standard" set of quantities so as to prevent > a "standard" quantity from having two different definitions at two > different places. That will teach me to put two orthogonal thoughts into one message ;-) OK, so maybe I'm issing something, but the other part of my message dealt with the notion of standard 'names', and why that is an important issue. I believe it's important for VisAD as well -- if I write code to work with, say, temperature and pressure, where will the translation take place between the "names" that I use in the program and the "names" that someone put into a database? I would hope that the software would not have to be changed everytime I aimed it at a netCDF file with a different "name" for temperature... Am i missing something, worrying about this connection to the databases? So I do support this, up to a point. Trying to provide an exhaustive list is impractical and should be left to the community as the needs arise. A "common" set is a fine idea. And I certainly don't think the WMO is going to make one up (beyond their "code symbols" which are not acceptable since they use subscripts and are otherwise 'unnatural' ;-) tom -- Tom Whittaker tomw@xxxxxxxxxxxxx Space Science and Engineering Center University of Wisconsin-Madison Phone/VoiceMail: 608/262-2759 Fax: 608/263-6738
visad
archives: