Re: quantity database

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