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
