Input: A dual region graphG= (N,E) from a floor plan.
Output: A coarser hierarchical graphH= (S,B) with subgraphs
s∈SofGas nodes and edgesb∈Bbetween subgraphs according to the partitioning ofGvia articulation points. find all articulation points (AP) ofG;
1
form subgraphs of connected articulation points;
2
form subgraphs of connected components of ordinary nodes
3
(CC);
split the connected articulation point subgraphs into decision
4
points (DP) and chains of ordinary articulation points (APChain);
merge all subgraphsCCwhich are connected to exactly one
5
decision pointDPwith the subgraph of the decision point; merge allCCwhich are connected to exactly one chainAPChain
6
with the subgraph of the chain;
for allCCwhich are connected to exactly two chainsAPChain1
7
andAPChain2, merge the three subgraphs into one subgraph
APChain12, unless there is anotherCC subgraph which is connected toAPChain1,APChain2,andanother chain ;
create a new graphH, with a nodesfor every resulting subgraph,
8
and an edgebfor every boundary-crossing edge between two different subgraphs;
returnH;
For larger and more complicated floor plans, it makes sense to apply Multi-Level
Hierarchisation this algorithmrecursively, i.e. using the output of the first application as input for the next application etc. (cf. the hierarchy level1graph in Fig.57). This methods yields successive hierarchy levels until the original graph is condensed to a single node. Decision points in the
original graph can – but need not necessarily – become articulation
points in the next coarser graph. The same holds for connected com- ponents between three or more chains.
Depending on the complexity of the floor plans, there can be more Number of Levels
or fewer levels in the hierarchy. The general idea of the presented algorithm is to converge quite quickly, so that there is not an overhead of too many hierarchy levels which represent only minor changes. For example, it makes no difference whether a long corridor is repre- sented as one region or segmented into several regions by intermedi- ate doors (e.g. because of fire security measures). Both representa- tions result in one chain of articulation points.
A hierarchisation for an entire floor is shown in Fig.58. For brevity,
Discovering the Main Circulation Structure with the Algorithm
only the main navigational structure is indicated by different colors:
the yellow regions are part of chains, green regions indicate decision points, blue regions dead-ends or connected components and red regions connected components between several chains or decision points. For more details on this and other examples, see Chap.6with a comprehensive evaluation.
Figure58: Hierarchisation of an Entire Floor
For the presented algorithm a proof-of-concept implementation has Animation of a Run
been successfully carried out. The implementation has been tested on
several floor plans of real buildings. As explained above, the results
of this study are shown in the next chapter. However we want to make clear how the algorithm works on a more detailed example, showing a prototypical run.
To give a first impression of this evaluation and to get a feeling for the application of the algorithm (with its recursive behaviour), consider Fig. 59. It illustrates an excerpt from an exemplary floor
5.4 f u r t h e r e n h a n c e m e n t s o f t h e h i e r a r c h y
plan together with the individual steps of the algorithm when the latter is applied to this floor plan. The diagram is to be read from left to right and top to bottom:
Figure59: Multi-Level Decomposition of a Floor Plan
The coloring scheme used in Fig.59is the same as for the previous ex- Illustrating the Recursive Behaviour ample of Fig.57: orange nodes indicate articulation points and green
nodes indicate decision points which are defined in this context as a special subset of articulation points (with three or more articulation points as direct neighbours). The blue nodes represent ‘normal’ nodes and those of connected components between articulation points. The first row in Fig.59shows the floor plan together with the correspond- ing graph structure. Articulation points (orange) and decision points (green) are then determined and the corresponding subgraphs are formed (left hand side of third row). Then the original graph is
simplified to a coarser graph which models the connections among
subgraphs (right hand side of third row). The coarser graph can
be obtained by simply replacing each subgraph by a representative node. In this new graph, the process is repeated: articulation points
are determined (left hand side of fourth row) and decision points (if there are any). Again subgraphs are formed and the simplification to a coarser graph is applied. This recursive process terminates when there is only one subgraph left, i.e. the next simplification would yield exactly one node.
There are of course possibilities to tune the parameters of the al- Factors Influencing
the Hierarchisation gorithm. This has an influence on how many hierarchy levels come out: One could for example leave the subgraphs of connected com- ponents and not merge them with subgraphs of articulation points. However, this does not seem to be practical since the subgraphs then become very small. Omitting the distinction between decision points and normal articulation points is another option. The result is that the hierarchy often converges quickly with only one level. A complicated circulation system is thus represented as one connected subgraph of articulation points, without the information on decision points. By giving stairs and exits of the building the same status as articu- lation points (which has been applied in the earlier version of the algorithm [SSO08]), one obtains more decision points. Consequently
the hierarchy converges a little more slowly without any additional
gain for path finding on the particular floor.
Articulation points also offer advantages in combination with context Further Use
information: For example, one can immediately see which parts of a building are not accessible by wheelchair. One just has to check if all articulation points fulfill the related constraints (e.g. are not of typestairs). In old buildings there can be long corridor systems separated by small stairs. In combination with geometric criteria (such as straight line of sight, stretched shape of regions, etc.), one can interpret chains of articulation points as corridors.
Although the proposed algorithm is quite efficient, it is intended
Dynamic Changes in
Floor Plans to be used in as a pre-processing step when the hierarchical graph model is constructed. In this regard another question naturally comes up: what about dynamic/incremental changes in the floor plan? This is for example relevant when we want to model a building under construction and provide navigation for it. In Sect.4.2 we have es-
tablished a notion of consistency for the individual operations for
constructing a hierarchical graph. Since the hierarchisation method
employed in this algorithm depends on the structure of the floor plan
graph, it is naturally vulnerable to changes in the underlying graph
structure.
A naive solution would be to run the algorithm again and again Possible Solutions
each time there is a change in the floor plan graph. If there are fre- quent changes and updates to the graph structure, this solution is not feasible. A better idea is to store the knowledge on articulation points and decision points used in the first run of the algorithm and check,
after each change in the floor plan, whether these assumptions still
hold. Note that there could also be new articulation points when an edge is added or removed, and this change could also affect e.g. that
5.4 f u r t h e r e n h a n c e m e n t s o f t h e h i e r a r c h y
former articulation points become decision points etc. In other words, cascading updates are likely so that a compromise seems sensible which consists of bundling changes/updates within a certain period of time (day/week). This problem is interesting from both theory and practice and certainly deserves further investigation in future work.
5.4.4 Summary
This section explained the necessity of enhancing the basic geometric model which has been introduced in the previous section to meet practical requirements and relevant cases which can occur in real floor plans. Especially the simple one-to-one mapping to a graph model turned out to be insufficient:
Sect. 5.4.1 presented a handful of examples from real floor plans
which cannot be properly handled with a straightforward mapping
to a graph structure. The sketched examples are not extremely rare
or exotic, but relevant in practice. A systematic analysis of these cases
has been carried out. The analysis revealed two main shortcomings of the simple mapping method: on the one hand, there are cases in
which the mapping is too coarse (e.g. non-convex polygons). On the other hand, there are cases where an intermediate abstraction level
is missing (such as the recognition of a bunch of connected regions
being a central/peripheral corridor structure).
In Sect.5.4.2, a solution was proposed for handling the case of non-
convex polygons by a specific way of exact cell decomposition. Unlike standard approaches from Computational Geometry, the proposed solution is notbased on triangulation. Rather, the method for per-
forming the decomposition takes into account what humans would perceive as ‘intuitive’ decomposition. The method adheres to princi- ples of Gestalt theory. The main idea is to derive meaningful spaces
by the division, and also the division lines themselves take up the role of soft boundaries. Thus, the approach fits nicely into the hierarchical model.
Sect. 5.4.3covered the second aspect. An algorithm was presented
which can extract meaningful subgraphs (which roughly match to concepts such as corridors and wings) from a flat floor plan graph. The algorithm has been successfully implemented and beyond, there is also a proof of concept on several floor plans which justifies the soundness of the underlying assumptions. The idea behind the algo- rithm is to use the topological structure of a floor plan for navigation: since floor plans are rather sparse, their corresponding graphs can be decomposed around articulation points. Not only does this second decomposition imply a wayfinding strategy or heuristic, but it also promotes the use of the resulting concepts (corridors, wings, etc.) as landmarks, serving as references in route descriptions.
5.5 a p p l i c at i o n: q u e r y p r o c e s s i n g u s i n g t h e h i e r a r c h y
Having defined different means for hierarchisation, the possible em- Synopsis
ployment of the resulting hierarchical graph structure for practical
navigation tasks in buildings is now demonstrated. Apart from the
inherent advantages of a hierarchy from the point of view of a sys-
tem’s design, such as flexible integration of different networks, it is
also shown that common wayfinding issues can be handled with the hierarchy:
pat h f i n d i n g is the first aspect. It can be improved with an under-
lying hierarchisation (see Sect.5.5.1). Despite the rather small
size of indoor graphs, performance can be an issue if many path queries are posed, or queries involve a class of possible destinations (e.g. anylecture room or emergency exit) rather than one single destination. The conditions under which one can exploit hierarchic graph structures (as opposed to flat graph structures) are examined for this purpose.
r o u t e d e s c r i p t i o n s. The second aspect concerns route descrip-
tions and their generation from the hierarchical model, includ-
ing the regions’ geometry. The basic methods for this are ex- plained in Sect. 5.5.2. Since dual region graphs are abstract
insofar as they describe regions as a whole, and not motion through a region, a hierarchisation into convex sub-regions has been proposed. Together with the geometries of the regions, the possible use of this hierarchisation for deriving meaningful route descriptions is shown. Moreover, the coarser hierarchi- sations into building parts, sections, floors, etc. serve as a convenient means for structuring several route instructions (this process is called chunking).
5.5.1 Using the Hierarchical Structure for Path Finding 5.5.1.1 Overview of Supported Queries
In general, a complete navigation system to be used in practice should support the following types of user queries [GNSW06]:
l o c at o r – Where am I? Where is object X? (generally, a Point Of Interest) And, especially for pedestrian navigation: What is my orientation?
p r o x i m i t y – Which persons/objects/Points Of Interest are close to my current location? This notion also includes range queries: Which ones are on the same floor/zone or within 50m?
way f i n d i n g – How do I get fromAtoBthe fastest/shortest way? The first point refers to positioning technologies. This aspect is not covered in this thesis, but the locations and current positions of persons, objects, and/or POIs can be annotated as attributes in the
5.5 a p p l i c at i o n: q u e r y p r o c e s s i n g u s i n g t h e h i e r a r c h y
graph structure, ensuring independence from a particular positioning technology (cf. Ohlbach et al. [ORLS06] for an overview on diverse indoor positioning systems and technology).
Within the proposed graph model, the term ‘near’ is understood in the strict sense of walking distance, taking into account the con- nections between regions via openings such as doors. An indoor positioning system, such as W-LAN fingerprinting [ORLS06], can
be used to determine the current location of a user. This location is
represented as a point in the geometric model (if the spatial reference systems are correctly mapped to each other). For assigning points of interests to regions (e.g. stating that they are of typelecture hallor that a friend/professor is currently in this room), the corresponding nodes
in the dual region graph can be annotated. Note that the semantics
of distance can be more elaborate with constraints, such as access restrictions. They can be specified in a cost function, which is passed on in the hierarchical graph system as a parameter to path finding
algorithms. Hence the hierarchical graph system serves as a flexible
framework for adapting general path finding methods to the view and preferences of individual users.
However, one question is eminently important for pedestrian in- The Role of Orientation door navigation. It is the question ‘What is my orientation?’: The
egocentric orientation of a wayfinder plays a crucial role in route descriptions, because all landmarks on the way are usually described from this perspective using qualitative spatial relations (left/right of the wayfinder’s current position). Thus the spatial reference system of a wayfinder is built around her/his orientation.
What are viable solutions to cope with this issue? One the one hand,
it is conceivable that spatial orientations of wayfinders are provided
by the currently employed indoor positioning system. Unfortunately, many of these systems are not (yet) capable of determining a user’s orientation because this is a technically sophisticated matter. Devices like gyroscopes or accelerometers of high precision have to be em-
ployed for this purpose, coupled with other positioning technology
to achieve satisfying results in accuracy.
Therefore, for our system design, we cannot rely only on an un- derlying positioning technology alone to provide us with information on spatial orientation. If information is available from a positioning system, we can gladly use it. But we need to consider as well the case when we do not have any additional information on orientation
a priori. Apart from an interface to accept spatial orientations from
positioning systems, we need to make some basic assumptions in the absence of this information. These assumptions should be kept as
minimal and unintrusive as possible. For this purpose we integrate
the concept of spatial orientation in our geometric model and use it for deriving meaningful descriptions for regions. For example, when going from one region to another one, an assumption is made that the orientation at the moment of entry is perpendicular to the tra-
versed portal/door. A methodology for deriving route descriptions
which employs spatial knowledge about such implicit orientations is explained in Sect.5.5.2in more depth.
5.5.1.2 Path Finding Example with the Hierarchy
What is the concrete gain of the hierarchy in terms of path finding?
To investigate this issue more closely, consider Fig. 60: It shows a
complex building with two floors.
First Floor
Ground Floor
Figure60: Finding Paths over Two Floors
A prototypical path finding problem over two floors is illustrated in the example. Suppose the task is to find an optimal path from the entrance hall on the ground floor to an office on the first floor (both are marked yellow). One can solve this problem the traditional way by performing a shortest path algorithm on the entire graph spanning across the floors. However, each floor may be stored sepa- rately, so that path finding methods are only available on the graphs of floor plans. One can still argue that the graphs of floors can be combined into one large graph. Although this works in the example, constructing one large graph does not scale in general. Say we have two building complexes instead of floors. This makes it difficult to represent the complete unified graph in memory. Besides, buildings
from different authorities/owners may not always be combined for
5.5 a p p l i c at i o n: q u e r y p r o c e s s i n g u s i n g t h e h i e r a r c h y
However, we can think about a distributed approach with hierar- chical graphs: Each floor is represented as a node in an abstract graph (which represents the building), with edges as connections be- tween floors. Each floor has a more detailed graph. Note that the start and end nodes are generally in different graphs when multi-level hier- archies of graphs are considered. So the first task is to find out which
graphs contain the start/end nodes. Instead of searching allgraphs