Unit Conversion

William Gu

Overview

The unit conversion is a complicated process while a large number of unit types are involved. In our implementation, we try to organize the unit types in a special data structure which can be easily stored in a relational database. Meanwhile, we try to keep the maximum flexibility.

The paper is presented in three sections:

1. Data Structure:  how to organize the unit types, how to code them, etc.

2. How to convert:  how to make the actual conversion with the above data structure

3. Where to store unit information:  where can we get the unit information, priority, etc.

Data Structure

Data structure is the internal organization of data. The user may not even know their existance. A system designer or programmer should have a very clear idea about it and make sure it supports the sufficient flexibility and quick response time.

• Unit Structure

Figure 1 presents the imaginary data structure for unit conversion. Here we list three unit systems: metric, english and other. Under each unit system, we define several unit types such as length, area, volume, etc. We define a preferred unit (or primary unit) for each unit type. At the lowest lever (leaf) we define arbitrary number of units belong to this unit type.
• Coding

RUSLE2 suggests using IDs that map to a name string, unit type, conversion factor, etc. We try to extend the idea which will make it easy to convert units. The basic idea is to hide some information in the IDs which represent the units.

For each unit, we use a 6-digit number to represent it. The meaning of each digit is as follows:
 

Code #	Digit #	Meaning	Examples
1	1	Unit Systems	Metric: 0, English 1, Other 2
2	2~3	Unit types	Length: 01, Area: 02, Volume 03,...
3	4	Is it preferred unit?	Yes: 1, No: 0
4	5~6	Serial #	00: for preferred unit, 01~99: for other unit types

For example, in figure 2, 001100 represents meter in length as the preferred unit type in the metric system. Likewise, 101001 represents inch in length as the first non-preferred unit type in the english system (refer figure 1). This ID will be kept with data elements in the model or database. Figure 2: Unit Coding
• Tables and Database

To store all these information in a relational database, we use several tables.

1. Unit System Table:
 

Unit System	Code
metric	0
english	1
other	2

 
2. Unit Type Table:
 

Unit Type	Code
length	01
area	02
volume	03
...	...

 
3. Unit Table:
 

ID	Unit	Conversion Factor	Other Info
001100	m	1 (this is the preferred unit under standard unit system)	...
001001	mm	0.001 (related to the preferred unit under the same  unit type and unit system, in this case "m")	...
101100	ft	0.3048 (since this is the preferred unit type for a non-standard unit system, the factor is related to the preferred unit under the standard unit type)	...
101001	in	0.083 (related to the preferred unit under the same unit type and unit system, in this case "ft")	...
...	...	...	...

In the above table, we show part of the table with metric system as the standard (native) unit system (code #1: 0). "m" is the perferred unit type(code #3: 1) of the length. That's why its ID is 001100 and its conversion factor is 1. "mm"(001001) is the unit under the length unit type of metric system. So the conversion factor is related to the preferred unit (001100 or "m") under the same unit type (length).

For unit "ft" (101100), it belong to the english unit system which is not the standard unit system (code #1: 1). It is a preferred unit (code #3: 1 and code #4: 00). The conversion factor is related to the preferred unit under the same unit type of the standard unit system, "m". That is

1 ft = 0.3048 m.

Note: If we know ft-m convresion factor, we also konw m-ft conversion factor. Also note the table above should have two index, ID and unit, so that we can search the record using either of them.

How to Convert?

With the data structure above, we can easily do conversions between any two convertable units. Convertable means they share the same unit type, i.e. same code #2 value. There are several possibilities for the unit conversion.

• Conversion within one unit system

Figure 3: Covnersion within one unit system

As indicated in figure 3, conversion within one unit system is easy. Just use the preferred unit as the bridge.

• Conversion between two unit systems
Figure 4: Conversion between two unit systems

In figure 4, we show two cases of unit conversion between two unit systems. The first one is simple. It converts from one preferred unit type to another preferred unit type. Since in the unit table, we already keep the conversion factor from ft to m. So we can convert either direction.

The second case is the most complicated one. In figure 4, red line 2 represents the unit conversion from "mm" to "in". Since we can get mm-m, m-ft and ft-in conversion factors in the table, the convertion factor for mm-in can be calculated by multiplying these three factors.

            mm      ->      m      ->      ft      ->      in

         001001          001100       101100      101001

Before we make the conversion, we know the ID for both mm and in. We can get the ID of the intermediate preferred units by changing related ID digits. For example, we can get the parent of "mm" by changing the last three digits to 100. With all these IDs as the keys, we can get the conversion factor very quickly.

• Make the conversion more quick

In the above explanation, we may do any conversion between two convertable units. But it may be slow especially for two non-preferred units across two different unit systems. To make this conversion faster, we can keep a cache table in memory with the two ID combined as the key.

Where Do We Store the Unit Information?

WEPS suggests three-level of unit information storage, i.e. DB-level, model-level (global) and view-level (local). At the DB-level, we store the unit information along with the database and/or files. At the model-level, unit information is attached with data elements. At the view-level, unit information is stored with each view. The priority order is view-level first, model-level next and DB-level last.

DB-Level

At DB-level, we have two choices for storing the unit information.

1. Store unit information along with all data elements. In this case, we need to setup a unit field in the database. Though it is space-consuming, it provides the maximum flexibility.

2. Use one single unit system and its preferred units. In this case, we just save the Code ID for the unit system. All the data in the database are stored with one unit system such as metric.

Model-Level (Global)

While the system is running, we keep model data in memory. The model data should have unit informaiton with it. That means when we read data from database, we may need to make a unit conversion to fit the user selected unit system. Unit conversion is also happened when the user selects a new unit system.

View-Level (Local)

Each view can have its own unit specification. This provides the maximum flexibility. User can set unit for any element in a view if the view allows. For example, in a table view, user may change a unit for one column and/or even one cell. The view will be responsible to keep track of what units are used.

Conclusion

The design of the system is to get the maximum flexibility. For example, we can create user-defined units such as PRECIP, FIELD_AREA, LENGTH-SHORT at the bottom of the tree. The system will treat them the same as other standard units. To make the conversion quicker, we use a cache table.

The system is still in the design stage. Please send your comments and suggestions to WEPS group.