In a previous research stage, a oneway linear coordinate method (OWLC) was proposed and implemented in SC_IN_DBMS to enable fast calculation of network distance between any two crashes. During a test, a major problem of OWLC was found. The problem is, when the base link and the candidate link are connected in a loop (directinal or indirectional), OWLC may misplace the candidate link in the linear coordinate system originated from the base link. For example, in Figure 1, the base link is
The essence of the above skew problem is that the shortest distances between the reference sites are either backward measured or forward measured with respect to the base link, but not consistent when being compared to each other. For example, OWLC compares dist_{TcFb} with dist_{TcTb} without noticing the former is measured through the backward route and the latter is measured through the forward route. So, to fix this problem, a twoway linear coordinate method (TWLC) is proposed below with dual shortest distances measured backward and forward, respectively.
In the following discussion, we assume the readers already read the SC_IN_DBMS framework and are familiar with some basic terms, such as base link, candidate link, STS route, etc. Also, without particular specification, F_{b} is used to denote the fromreferencesite of a base link, and T_{b} for the toreferencesite. Additionally, RS is used to denote any reference site in the STN network, and can be substituded with any other notation of a reference site. The following two parallel concepts are the most important and elementary terms in the successive discussion:
The TWLC method consists of three algorithm modules, each fitting into a certain level of process in the framework:
for every base link b{ Module 1: Traverse to Collect Shortest STS Routes and Identify Candidate Links for every crash prim in base link b{ for every candidate link of b, c{ for every crash scnd in link c{ if prim happened before scnd{ Module 2: Calculate the Network Distance if b and c are on opposite directions of the same highway{ Module 3: Validation Using Highway Name and Direction Information } } } } } }
When reading the following details about the three modules, one should always keep in mind the right contexts of the modules as they fit into the framework. For example, the explanation of Module 1 is in a perbaselink context. Every task in Module 1 should be redone for every new base link. Also, the results from Module 1 are only associated with the corresponding base link.
The traversing goes two ways: forward and backward. The purpose of the forward traversal is to reach every RS whose shortest
workingList : a FIFO queue each of whose elements is a data pair (RS, STS route).FRTTable : a hashtable with key = RS and value = STS route.BRTTable : a hashtable with key = RS and value = STS route.candLinks : a list of all candidate links.df : the distance filter.mll : the maximum link length.
Forward traversal pseudo code:
allocateworkingList ; allocateFRTTable ;// Initialize FRTTable hashPair = [k : F_{b} v : an empty STS route()]; addhashPair toFRTTable ;hashPair = [k : T_{b} v : a STS route() containing only the base link]; addhashPair toFRTTable ;// Initialize workingList dataPair = [v1 : T_{b} v2 : a STS route() containing only the base link]; adddataPair toworkingList ;// Traverse until the end of the growing workingList is reached whileworkingList is not empty{dataPair =workingList gets the first element;curRS =dataPair .v1;curRoute =dataPair .v2;workingList removes the first element;nextLinks = a set of links connected tocurRS ; for each linknextLink innextLinks { ifnextLink is not the last link incurRoute {nextRS = the other RS ofnextLink instead ofcurRS ; ifnextRS is neither F_{b} nor T_{b}{nextRoute =curRoute ;nextRoute appendsnextLink to the end; ifnextRoute <=df +2*mll { ifnextLink is not yet incandLinks , add it tocandLinks ; ifFRTTable containsnextRS as a key{tmpRoute =FRTTable .valueOfKey(nextRS ); ifnextRoute <tmpRoute {FRTTable .valueOfKey(nextRS ) =nextRoute ;dataPair = [v1 :nextRS v2 :nextRoute ];workingList appendsdataPair to the end; } } else{hashPair = [k :nextRS v :nextRoute ];dataPair = [v1 :nextRS v2 :nextRoute ];FRTTable putshashPair in;workingList appendsdataPair to the end; } } } } } }
Backward traversal pseudo code:
allocateworkingList ; allocateBRTTable ;// Initialize BRTTable hashPair = [k : F_{b} v : an empty STS route()]; addhashPair toBRTTable ;// Initialize workingList dataPair = [v1 : F_{b} v2 : an empty STS route()]; adddataPair toworkingList ;// Traverse until the end of the growing workingList is reached whileworkingList is not empty{dataPair =workingList gets the first element;curRS =dataPair .v1;curRoute =dataPair .v2;workingList removes the first element;nextLinks = a set of links connected tocurRS ; for each linknextLink innextLinks { ifnextLink is not the last link incurRoute {nextRS = the other RS ofnextLink instead ofcurRS ; ifnextRS is neither F_{b} nor T_{b}{nextRoute =curRoute ;nextRoute appendsnextLink to the end; ifnextRoute <=df +2*mll { ifnextLink is not yet incandLinks , add it tocandLinks ; ifBRTTable containsnextRS as a key{tmpRoute =BRTTable .valueOfKey(nextRS ); ifnextRoute <tmpRoute {BRTTable .valueOfKey(nextRS ) =nextRoute ;dataPair = [v1 :nextRS v2 :nextRoute ];workingList appendsdataPair to the end; } } else{hashPair = [k :nextRS v :nextRoute ];dataPair = [v1 :nextRS v2 :nextRoute ];BRTTable putshashPair in;workingList appendsdataPair to the end; } } } } } }
During the above two traversals, candidate links are identified on the fly. A link is considered to be a candidate link if: 1) it is reached as the
Module 2 deals with the calculation of the network distance between two specific crashes, the prim (on the base link) and the scnd (on the candidate link). The first step is to locate all reference sites on the linear coordinate system (
Reference Site  Backward Coordinate  Forward Coordinate 

Base Link  
F_{b}  
T_{b}  
Candidate Link  
F_{c}  F_{c}^{b} = 
F_{c}^{f} = 
T_{c}  T_{c}^{b} = 
T_{c}^{f} = 
Next, the coordinates of crashes are to be determined. Depending on whether some coordinates of the reference sites are available, there can be a couple alternative coordinates for the secondary crash scnd. The formulas are given in Table 2.
Table 2. TwoWay Coordinates of CrashesCrash  Backward Coordinate  Forward Coordinate 

Base Link  
prim  p = 

Candidate Link  
scnd  if T_{c}^{b}  F_{c}^{b} == length of the candidate link s^{b} = 
if T_{c}^{f}  F_{c}^{f} == length of the candidate link s^{f} = 
else, s^{b} = 
else, s^{f} = 
At last, the distance between the two crashes is determined through the following equation:
Dist_{primscnd} = 
.......... Equation 1 
If Dist_{primscnd} = s^{dir}  p (where, dir = b or f), whether scnd is upstream or downstream of prim is its own direction can be determined through the following sign equation. If Sign_{primscnd} > 0, scnd is downstream of prim in the direction of the candidate link; if Sign_{primscnd} < 0, scnd is downstream of prim in the direction of the candidate link; otherwise, scnd and prim overlap. If either of T_{c}^{dir} and F_{c}^{dir} is null, Sign_{primscnd} is made positive.
Sign_{primscnd} = 
.......... Equation 2 
Figure 2 illustrates how TWLC solves the problem mentioned at the beggining of the document. In this case, the final distance is min(dist^{forward}, dist^{backward}) = 12.6 miles, which is the correct result.
Although TWLC solves the problem when highway loops are involved, there is another problem remaining if the highway name and the highway direction of each link are not known. Figure 3 illustrates this problem. Highway STH 90 goes EW, and there is a segment
The proposed validation process requires highway name and direction information of each link. In Step 1 of the program framework, links are loaded from the DT_RDWY_LINK table with some basic properties. Two additional properties need to be loaded from a table named DT_RDWY_RTE_LINK. The two properties are highway name and highway direction. Highway name is the name of the highway which the link belongs to. Hightway direction is the traffic direction of the link on that highway. For example, in Figure 3, the highway name of the base link and the candidate link are both "STH 90", but the highway direction of the base link is "E" and the highway direction of the candidate link is "W". The validation (Module 3) is activated if the base link and the candidate link have the same highway name but different highway directions (i.e., on opposite directions of the same highway).
The basic idea of the validation process is to find the first shared reference site of both highway directions upstream and downstream of the base link (or downstream and upstream of the candidate link), respectively. The difference between the distances from crash prim and crash scnd to the first shared reference site upstream of the base link (or downstream of the candidate link) is noted