Kovacs and Galle proposed a reasonable design heuristic that if an angle is too big between where the pedestrian wants to go and the available walkways then they might take a short cut over the lawn. There are no empirical studies for this heuristic but it seems like a reasonable assumption. With IWalkways, this angle is user-definable so it allows for some degree of flexibility.
What this means graphically is that if in figure 1 a person wanted to get from the top node to the bottom node, they will only tolerate intermediate nodes within the specified oval. The oval is defined by the user-specified angle shown in red on figure 2.
|
|
|
figures 1 and 2: the detour heurisitc around the center node says that the pedestrian will probably not take a shortcut between the end nodes. The oval is defined by the red angle which is user customizable. In this case it is 120 degrees.
End nodes, such as in figure 3, have a different way of visualizing the detour constraint. Namely that two guidelines are created to show valid placements for the top node which adhere to the detour constraint (if it is not possible to keep the detour constraint then we would have a case such as in figure 8).
figure 3: the detour heuristic around the top node. Note that the guidelines are constructed from the line connecting the middle and bottom node.
When a node does not satisfy the detour heuristic, the oval turns magenta to signify to the user that there is a problem (figure 4). Arcs can only be either magenta or grey, and nothing in between (see the conclusion on why).
figure 4: the center node is violating the detour constraint.
The detour filter gets increasingly rich with information as the number of nodes increases. Figures 5 and 6 demonstrate solving for multiple nodes. In figure 5, it is impossible to enable a pedestiran to walk from all extremety nodes to any other (this can only happen in the special case when the nodes are exactly 120 degrees from each other). If the designer feels that it is acceptable to lower the tolerance, they are free to change the angle measure (figure 6).
|
|
|
|
detour angle=120o |
detour angle=100o |
figures 5 and 6: solving for multiple detour constraints.
Figures 7 and 8 show how the system helps solve for multiple incoming edges into an end node. The valid angle range shrinks as more nodes are added and eventually disappears and is replaced by an "x" to signify that there is no way to walk from the top node to the center point and then to every other point without violating the detour angle requirement. This is not necessarily bad, since for example in figure 8, the node to the right might not be of any interest for someone coming from the top of the graph.
|
|
|
|
valid range of angles for the top node to connect into the lower |
no valid placement for top node to connect every other node |
figures 7 and 8: multiple detour constraints for an endnode (at the top). In figure 7, anywhere between the grey markers will be a valid place to connect the top node to any of the bottom nodes and stay within the angular constraints (in this case it is 120o). Since there is no valid placement for a node in figure 8, IWalkways draws the small magenta "x" through the node it is attatched to.
The detour heuristic does not draw a detour line between nodes which are already connected (see figure 9). But it does draw some unnecessary guide arcs when two nodes are connected by a third (see figure 10).
figure 9: The arc between the leftmost node is not drawn since the system "sees" a direct link between the two vertices and hence, it is not necessary to go through the center node to get between them (in contrast to getting from either of the left nodes to the right node).
figure 10: when dragging the node on the right, a potential detour is incorrectly cited since the system does not "see" that there is already a very direct way between the top-most and bottom-most node which runs though a middle node.
