Cognitive OpenLS Extending XML for location services by a high-level cognitive framework

Transcription

1 Cognitive OpenLS Extending XML for location services by a high-level cognitive framework Diplomarbeit Fachbereich Informatik, Universität Bremen April 10, 2006 Stefan Hansen Betreuer: Dr. Alexander Klippel Kai-Florian Richter Gutachter: Prof. Christian Freksa, Ph.D. Dr. Alexander Klippel

2

3 Abstract Web applications and location based services providing geo spatial information is increasing more in popularity. Consistently, providing the user with directions describing how to navigate from location A to location B has been one of the most popular services of these applications. The calculation of routes is solved sufficiently for routes in street networks, but how to generate route directions that are understandable and easily to follow, i.e. that are cognitive ergonomic, is still an open question. The aim of this thesis is to contribute in answering this question. It closes the gap between collecting the required information and the actual generation of cognitive ergonomic route directions. Therefore, a data model is developed for encoding the information necessary in order to generate route directions which regard aspects of cognitive ergonomics: making direction concepts more precise, using landmarks and chunking route parts. Furthermore, the data model is integrated into the OpenLS specification an open standard for location based services. This allows a path for an easy implementation and helps to integrate aspects of cognitive ergonomic route directions in future applications. 3

4

5 Contents 1 Introduction Approach and goal Structure of the thesis Cognitive ergonomic route directions Making direction concepts more precise Direction Models Naming the structure Using landmarks in route directions What can be used as a landmarks? Automatically generated directions using landmarks Functions of landmarks in route directions Landmarks at the start point Landmarks at the end point How to describe landmarks? Subsuming route directions Spatial chunking Segmenting route directions Extending and combining Klippel s and Dale s approaches 39 3 Analysis of current navigation services Making direction concepts more precise Example: Fork intersection Example: Competing branches Example: Roundabout Landmarks in navigation services Landmarks in stadtplaene.klicktel.de Subsuming route directions Street name chunking Road hierarchy chunking Summary of results OpenLS The OpenLS framework Top-level architecture

6 Contents XML based languages in OpenLS The OpenLS services Route directions with OpenLS Route directions in the route service Route directions in the Navigation Service Data structure of the Navigation Service NavigationResponse Structure of the route directions Data type of a single instruction ManeuverType: Extending the AbstractManeuverType Cognitive ergonomic route directions in OpenLS Making direction concepts more precise Using landmarks Subsuming route directions Why has OpenLS been chosen as basis? Advantages Disadvantages Extending OpenLS Used approach for the integration Regarded aspects of cognitive ergonomic route directions Technical realisation Extending RouteManeuverList XStartingManeuverType XEndManeuverType Introducing XManeuverType Deriving from AbstractManeuverType New introduced elements and attributes Replacing NextSegment by CurrentSegment Making route directions more precise Direction model Naming the structure Types representing intersections Integration of landmarks in OpenLS AbstractLandmarkType Landmarks for orientation at Start and End Point AbstractNElementLMType Abstract1ElementLMType Description of Landmarks Subsuming route directions ChunkType AbstractChunkElement Summary

7 Contents 6 Usage of the proposed data structure Example 1: A complete route Example 2: Spatial chunking Example 3: Competing branches Review of the examples Conclusion What has been done? Review of the implemented features Implementation of the aspects of cognitive ergonomic route directions Using the proposed data structure in reality Outlook and future work More cognitive ergonomic route directions Making the extension part of the standard A Appendix 129 7

8

9 1 Introduction Internet services providing geo spatial information is increasingly gaining popularity. Due to new techniques (e.g., AJAX: Asynchronous JavaScript and XML) these services become more and more user friendly. Major companies such as Google and Microsoft continue to push new services and applications into the market. Geo spatial web applications and location based services (LBS) have already become an inherent part of today s Internet. At all times, providing the user with directions describing how to navigate from location A to location B has been one of the most popular services of these applications. Independent of the awoken interest, wayfinding and route direction have always been in the interest of scientists from various areas. As far as street networks are concerned the task of calculating routes between two locations is a well understood and sufficiently solved task. The technical aspects of calculating routes have been adequately addressed. However, assumed having calculated a correct route between two locations, the next and not sufficiently solved problem is how to present this information? How can this be done in a way that is understandable for a human and easily to follow? Which aspects are important for the human understanding of the given instructions? Which information has to be provided? How should it be presented? Answering these question would lead to route directions adequate for humans. In this thesis, route directions easily perceived and naturally understood by humans will be referred to as cognitive ergonomic route directions. The next question that arises in this context is how to integrate the results of these questions in the process of generating route directions automatically. Robert Dale et al. [5] assume, that automatically generated route directions close to those created by humans are preferable. This hypothesis arouses questioning, what route instructions generated by humans look like and which aspects are important for the human understanding of route directions. Answering this will be an important step towards automatically generated and cognitive ergonomic route directions. Numerous scientific articles have been published addressing some aspects of the nature of human generated route directions and of their automatic generation. The task of generating cognitive ergonomic route directions automatically splits into two steps. First, all information that will be presented later must be extracted from the underlying data sets. Based on the collected information, the actual instructions are then generated in the second step. The Open GIS Consortium (OGC) developed an open and interoperable stan- 9

10 CHAPTER 1. INTRODUCTION dard for accessing open LBS server, the Open Location Services (OpenLS) standard [30, 2]. The implementation specification includes the so called Navigation Service, which provides amongst others, information necessary for the second step, i.e. for generating route instructions. The Navigation Service defines the communication between the server producing the information and a client producing the route directions. For easing the transfer, the information is stored in a XML based data structure. This represents exactly the data structure required after the first step of generating route directions. This work addresses the question: Does the data structure defined in the OpenLS specification contain the information required to generate cognitive ergonomic route directions? And if not, how can it be extended in order to allow for this? 1.1 Approach and goal The OGC does not commit the navigation part of the OpenLS specification to a certain area of application. For example, it is supposed that it is possible to produce route directions based on the transferred information for car drivers as well as for pedestrians, including the usage of public transport. However, instructions for car navigation and for pedestrians have different requirements. The Navigation Service offers the client to select the natural language used, without differentiating in the data structure between different language aspects (e.g., different verbal expressions for turns). The scope of this work is restricted, as it aims for route directions given in English and accordingly, for the Anglo Saxon cultural background. Aspects of the users personal preferences or their familiarity with the environment are not regarded. The route directions are intended to be used only for car navigation, since most of the scientific publications are transferable. The requirements on route directions also depend on the environment. Navigating on an open field is different to following a route in a street network. A rural area possesses other requirements than a city environment. Hence, this work will deal with inner city street networks. Even the topic of cognitive ergonomic route directions comprise a wide area with many different aspects and must be restricted. Hence, this work will focus only on three of them: Making direction concepts more precise Using landmarks Subsuming route directions Within this scope, the related scientific publications will be discussed, the OpenLS Navigation service and additionally, some commercial web based provi- 10

11 1.2. STRUCTURE OF THE THESIS ders of route directions will be examined and the results integrated in the OpenLS specification. The extended version of the data structure of the Navigation Service will comprise the aspects identified in the discussed publications. As basis for the further generation of route directions, it contains already the relations between the objects integrated in the instructions, for example, between a landmark and a decision point. This constrains the generation of the directions and implies the cognitive ergonomic aspects. 1.2 Structure of the thesis Since there are numerous aspects which potentially have to be considered in order to generate cognitive ergonomic route directions, this work focuses on three different aspects of route directions: Making direction concepts more precise, the usage of landmarks and subsuming route directions. Each chapter will examine these and discuss them from different viewpoints. This thesis is structured in seven chapters, including the introduction, which aim on the integration of the three covered aspects of cognitive ergonomic route directions in the specification of the OpenLS navigation service. The chapters discuss the following topics: Cognitive Ergonomic Route Directions The second chapter discusses scientific publications dealing with the three covered aspects of cognitive ergonomic route directions. For each of them the available approaches are examined, initiating a new combined approach. Analysis of Current Navigation Services In the third chapter current navigation services are examined. This answers the question of what extent the results discussed in the second chapter can already be found in the provided route directions. Open Location Services Specification OpenLS functions in this work as framework for a data model, which allows for generating cognitive ergonomic route directions. Chapter 4 describes in detail the OpenLS specification, its services and their functionality. Here, the focus is on the Navigation Service and on its data structure. It will be assessed on whether the data structure is already appropriate for encoding the information required for generating cognitive ergonomic route directions. Extending OpenLS In chapter 5 an extended data structure for the Navigation Service is proposed, which supports the aspects discussed in chapter 2. The newly introduced data types and their functions are detailed. Examples for using the proposed data structure The usage and the functionality of the data structure proposed is in the sixth chapter demonstrated 11

12 CHAPTER 1. INTRODUCTION by three examples. Each example focuses on different features of the data structures. Conclusion In the last chapter the results are summarised and reviewed. It is discussed, how far the posed questions could be answered and where problems remain. Also some possible approaches to extend the work are given. 12

13 2 Cognitive ergonomic route directions Communicating knowledge about a route is a common task in our everyday life. Describing to another person how to get from location A to location B has been done at some time by probably everyone. However, the problem of how this can be done automatically in a way that is easy to understand and to follow is not yet solved. There are manifold scientific publications dealing with this question to establish, how so called cognitive ergonomic route directions have to look like in order to be appropriate for human understanding. Hence, many of these articles analyse route instructions generated by humans to find important aspects of route directions and adapt them for the automatic generation of route instructions. The following chapter will discuss results of current research on three aspects of human ergonomic route directions: Making direction concepts more precise Using landmarks Subsuming route directions 2.1 Making direction concepts more precise In general, navigating along a route can be seen as making direction choices at decision points and therefore, giving route directions can be seen as describing the necessary directional changes (e.g., [21, 7]). Hence, the description of directional changes is the basis of a route instruction and one of the most pertinent parts in generating route instructions. The cognitive situation model has to match spatial situation. In this section, two approaches are discussed; both try to improve the accuracy of the description of turns and thus decrease the possible ambiguities Direction Models Since the description of turns is the basis of giving route directions, processing and representing angular information is an essential and crucial part in wayfinding and route planning (cf. e.g., [41, 13, 21]). Due to its important role in route 13

14 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS instructions, angular information is indispensable for the human understanding of the directions. Thus, its description must be as unambiguous as possible. In order to achieve this goal, human mental conceptualisation of this angular information and the mental representation of direction concepts has to be regarded in the generation of route directions. In the article Direction Concepts in Wayfinding Assistance Systems, Klippel et al. [20] analysed on behavioural basis the mental conceptualisation of directions concepts in city street networks and developed a direction model. In the following section the approach of the article and the resulting model will be outlined. Approach used by Klippel et al. The navigation in a city street network has special requirements on the mental representation and processing of angular information. For example, the wayfinding process in open space is not structured by roads, is completely different compared to navigating in a street network. Since the article, and especially the underlying experiments, focus on city street networks, the results presented may not be apt for situations outside a city. To date, scientific publications which propose direction models are based on the commonly accepted assumption that humans do not remember exact angular information of a street network, but conceptualise it qualitatively. The human mind structures the space in such networks in different, not overlapping categories. These models usually divide the space in homogeneous sectors (e.g. [11, 15, 14]). Klippel et al. [20] tried to experimentally identify, how the conceptualisation of directions appears and in how many different categories the space at an intersection is structured in the mental conceptualisation. Based on their results they developed a new direction model, which claims to be more similar to the one humans use in their mental conceptualisation. This model shall serve as basic model for direction concepts at intersections in city street networks. Proposed Model The model Klippel et al. provide in their article differs from earlier proposed models. It does not partition the space into homogeneously sectors. Instead, they take up the idea of using axes in the direction model (e.g. [12, 28]) and combine it with the common sector based models. The new proposed direction model (cf. Fig. 2.1) consists of six sectors plus one axis (plus the back sector, which is not further examined in the article). The sectors are not uniform anymore, their size varies. The sector representing the direction straight is replaced by an axis. The whole model is symmetric with respect to left and right. 14

15 2.1. MAKING DIRECTION CONCEPTS MORE PRECISE Figure 2.1: Original model with homogeneous sectors for each direction (left) and according to Klippel et al. revised direction model. The black lines represent prototypical directions as used, for example in [19, 20]. The figure is taken from [20] Naming the structure As mentioned before in section 2.1, giving route directions means mainly describing the directional change the traveller has to perform at the decision points. As Klippel et al. indicated in [20], the direction model depends also on the spatial structure of the intersection, where the traveller has to perform the described action. Therefore, it is necessary to integrate the spatial structure at the decision point in the given instruction in order to describe the required turn unambiguously. Different spatial structures of intersections A direction should be simple, easily understandable and unambiguous. However, this is often difficult, since spatial situations can be complicated to describe. Klippel et al. explain the problem by giving the following example: Figure 2.2 shows four intersections with different spatial configurations. At each intersection the traveller has to perform the same directional change, a 45 turn to the right. Since the spatial structure is different at each decision point, giving the same direction for all intersections would not lead to precise, unambiguously and therefore, to insufficient results in some cases. For example, the directional change at the roundabout in picture C has to be completely different to the direction for the intersection in picture A. An adequate direction for A would be, for example: Turn right. Whereas for picture C, a more appropriate instruction would be: Take the third exit at the roundabout. 15

16 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS A B C D Figure 2.2: The same directional change in combination with four different types of intersections (cf. [21]). Therefore, cognitive ergonomic route directions should regard the spatial situation at an intersection and integrate it in the description of the action the traveller has to perform. This will make it easier to understand them and to follow the given instruction. Competing branches Another problem with giving route directions are competing branches at intersections [21]. The term competing refers in this context to two streets branching off at an intersection in a similar direction. If one of the competing branches is out going branch of a route, the usually used verbal expressions such as left or right do not single out sufficiently one branch. Figure 2.3: Two competing branches at an intersections. Figure 2.3, for example, depicts an intersection with two competing branches on the right side of the intersection. Giving an instruction with an even super modified direction concept [20], like 16

17 2.1. MAKING DIRECTION CONCEPTS MORE PRECISE Veer slightly right. would in this case lead, still, to an ambiguous instruction. Route directions should try to disambiguate these spatial situations. Otherwise it will be difficult for the traveller to follow the described instructions. How humans deal with competing branches Based on analysing humans utterances Tenbrink and Klippel [26] found, that people solve the problem of competing branches quite often by naming the structure of the current intersection in combination with a coarse direction or an ordering concept within a route instruction. Describing the spatial structure of an intersection helps travellers to understand the given instruction and thus, to perform the required action. Based on the description they are able to create a mental model of the situation and of what they have to expect at the next intersection. Therefore, it is easier for them to identify the intersection itself and additionally, they have a more concrete idea of the required action and possible difficulties. Giving a coarse direction might be quite often sufficient, since the structure of the intersection constrains the possibilities of interpreting the direction. This allows for using simpler descriptions of the directional change (e.g., left instead of sharp left) and therefore, simplifies the instruction. Directional changes at some categories of intersections (e.g., at roundabouts) are often better described by an ordering concept. An example for such a direction is the aforementioned instruction: Take the third exit at the roundabout. Thus, the branches are ordered (e.g., in the case of a roundabout according to the order in which the traveller is passing them) and then the number of the out going route segment in the order is given. A solution for automatically generated route For generating route directions automatically, the approach humans use for disambiguating difficult spatial situations can be emulated. The description of an intersection s spatial structure has to be integrated in the instruction and the directional change must be given by a direction concept appropriate for the type of intersection. In this work for describing the situation at a decision point several prototypical intersections are defined (cf. [21]). Whether a coarse direction or an ordering concept should be used is also determined in the definition of the categories. The given direction depends then on the type of intersection and the actual spatial configuration. The classes of intersections proposed are outlined in this section: 17

18 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS Intersections without a competing out going branch These intersections require a coarse direction in order to describe the necessary action sufficiently. This category is split into three sub classes: standard intersections, fork intersections and T intersections. Fork intersections as well as T intersections have a salient and easy identifiable spatial structure and therefore, have their own special class (cf. Fig. 2.4). T intersections are all intersections, at which the street the traveller is approaching on ends in an orthogonally running street. At Fork intersections the road the traveller is on forks in two in terms of size almost equal streets. The angle between the incoming route segment and each the branches should be bigger than 90. A) B) Figure 2.4: Example of A) a T intersection and B) a fork intersection. These characteristics allow for encoding the spatial structure implicitly by the type of the entity. Both types force the traveller to perform a directional change. Going straight is in both cases not possible and both offer only two options to turn. Both possibilities to turn have to be equal. Travellers must not possibly assume, that they are just following the main road by taking one of the branches. This could be interpreted as going straight. Hence, these two types of intersections have to main characteristics they force the traveller to change his direction and offer him only two possibilities. These characteristics enable the unambiguous identification of this type of intersection and determine the direction concept. Both categories are combined with a simple and coarse direction. Since straight is not an option, both branches can be distinguished by referring to them by using left or right. Standard intersections are all other intersections which have no competing branches and also not a structure salient enough to function as landmark. Having no competing branches means that the out going segment of the route at this intersections is the only one on its side (left or right) or it just goes straight. Therefore, a coarse instruction like right, left or straight is already unambiguous. Additionally, the exact spatial configuration of these 18

19 2.2. USING LANDMARKS IN ROUTE DIRECTIONS intersections has to be stored separately. This is necessary, for example, for providing pictograms of the spatial situation. Standard intersection with a competing out going branch The description of the directional change changes if the out going route segment is competing with another branch. Then a coarse direction is not sufficient anymore or otherwise the instruction would become ambiguous. Hence, using in the instruction an ordering concept as mentioned above leads to better, unambiguous results. How to order the branches at such an intersection is still an open question. It is quite common to divide the branches in a right and a left group and order only the street in the group of the out going branch. Here, it has to be indicated beforehand, whether they are ordered clockwise or not, because this is not obvious for the traveller. A possible route instruction for such an intersection would be, for example: Take the second left. Roundabouts The category for roundabouts is split into two sub categories. The first part covers small roundabouts, which have not more than four branches. The branches should also be clearly arranged, so the traveller easily overlook the spatial situation. Large roundabouts have more branches and the single possibilities the traveller can use to exit the roundabout are not immediately identifiable. The description of the directional change at a roundabout depends on the sub category the roundabout is filed under. For a small and clearly arranged roundabout with no competing branches a coarse direction is completely sufficient. If the roundabout is so large, that the traveller cannot get easily an overview over the current situation, the usage of an ordering concept as mentioned above is more appropriate. 2.2 Using landmarks in route directions Landmarks are widely used in route directions given by humans and are one of the most important parts of the environment used for wayfinding and route following (e.g., [35, 32, 7, 8]). Landmarks allow humans to structure environmental knowledge [16], for example, as anchor points for spatial knowledge [3]. According to Michon and Denis [31], landmarks can be found in all parts of human generated route directions. They are used especially at the start and the end point of a route and in graphical, as well as verbally given instructions [7, 40]. Humans utilise landmarks for indicating elements of the route in order to assure travellers that they are still following the correct way, or for specifying a described action linked with the environment (e.g., a decision point) [7]. In route following landmarks work even better than street signs [37]. 19

20 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS In the following sections some aspects of the usage of landmarks in route directions discussed in scientific publications and the results of this research are outlined What can be used as a landmarks? Since landmarks play such an important role in human generated route directions, the question arises, which objects are suitable to be used as a landmark? Manifold definitions of landmark can be found. One of the first is given by Lynch [29], which is still the basis of many articles dealing with landmarks. As the key characteristic of a landmark he identifies its singularity, which refers to aspects that are unique or memorable in the current context. Presson and Montello [32] define every object, that stands out of the background, as landmark. Whether an object can function as landmark or not is determined by its salience. The easier an object is distinguishable from the background, the more salient is it and the better identifiable by the traveller [32]. If salient enough [22] even road intersections can be used as landmarks in the context of route following. As measure for the salience of an object, which may be used in the automatic identification of possible landmarks, can be a combination of different visual, structural, and semantic aspects [33] Automatically generated directions using landmarks There are several approaches dealing with the automatic generation of route directions, that consider the integration of landmarks into the instructions [34, 5]). The process of generating automatically route directions including landmarks, can be divided in the following steps (cf. [9]): 1. In the first step all objects, which can potentially function as landmarks, are identified and stored in a database. This step is independent from an actual route and can be done once beforehand and the results can be reused for any route. It only has to be redone, if the underlying base data changes. GIS data [1] or even data extracted from the Internet [38] may be used as underlying data. 2. The requested route is calculated and all landmarks, that can potentially serve as landmark for that route are identified. 3. Then the landmarks identified in the previous step are rated. This can be done, for example, according to their salience [42, 27]. The most useful landmarks are selected to be integrated in the route directions [9]. 4. Based on the chosen landmarks more advanced methods of integrating cognitive ergonomic aspects of route directions (cf. section 2.3) can now be applied to the current data set. 20

21 2.2. USING LANDMARKS IN ROUTE DIRECTIONS At this point all necessary data for generating route directions is collected and the route is structured according to instructions, that are generated later. 5. In the final step, the actual route directions are generated Functions of landmarks in route directions In route directions, landmarks may serve different purposes which are reflected in different conceptualisations. One of the factors determining the purpose of a landmark is the number of route elements the landmark is used for. Route elements are either decision points or route segments. Accordingly, a route consists of a sequence of alternating decision points and route segments [19, 7]. Klippel et al. propose in [23] a taxonomy, which allows to formally classify landmarks used for route directions. There, landmarks are categorised according to how they are conceptualised as an element of wayfinding and route directions. Based on this categorisation the function of a landmark in a route direction can be easily described before generating the final instructions. Already Lynch identifies in his seminal work The Image of the City [29] five elements, that are used by humans in their mental model of a city: nodes, edges, districts paths and landmarks. Besides structuring a city, they can also help to structure wayfinding and route directions. The elements of a city Lynch identified can all function as landmarks in route directions, if they are salient enough. This is adopted in a wider definition of landmarks used in Klippel et al. s approach. There, landmarks are not only outstanding objects, but all of the five elements identified by Lynch. The taxonomy used is given as a tree, where every node represents a characteristic of a landmark. At first, landmarks are categorised according to their function within an instruction. The following intermediate levels are further classified into more specific categories. In the final differentiation, landmarks are distinguished according to their spatial relation with respect to a route. The first four levels of the proposed taxonomy are shown in figure Root level The basic concept in this taxonomy is landmark. Hence, it is listed at the root level. (cf. Fig. 2.5) Functional level The Functional level contains two different groups of landmarks. The distinctive feature is whether the landmark is relevant for one single route element (1 Element) or for a sequence of more than one route element (n Elements). 1 This taxonomy reflects the current state as this is ongoing work. 21

22 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS Root Level Landmarks Functional Level n elements 1 element Conceptual Level Area Line Area Point Identified Elements not identify ing last DP not identify ing last DP Identifying last DP nondp DP Figure 2.5: The first four levels of the taxonomy of landmarks. Conceptual Level On the Conceptual level landmarks are categorised by the way humans conceptualise their spatial nature. They may be mentally represented by a point like (Point), linear (Line) or areal (Area) concept depending on the role they play in the route following process. That means, geometrically higher order landmarks (with area line point) can be conceptualised as a landmark of a lower geometrical order. For example, an areal or linear landmark can be referred to in an instruction as a point like landmark (cf. Fig. 2.6). The characteristics of the different categories are outlined in the following: a) b) c) Figure 2.6: Landmarks conceptualised as point like with a) a point like, b) a linear, and c) an areal geometry; the corresponding instruction is Turn right at the landmark. Point Landmarks of this type are located only at one single element of the route. This can be either a decision point or the route segment. They describe either the action at the route element or simply facilitate the identification 22

23 2.2. USING LANDMARKS IN ROUTE DIRECTIONS of a route element in order to reassure the traveller. Notwithstanding their actual geometrical form humans conceptualise them as point like entities. Line In contrast to point landmarks, line landmarks are not only relevant for one single route element. They are rather used to describe several consecutive route elements. These types of landmarks are especially used for combining elementary instructions to one single route direction (cf. section 2.3). Regardless of the geometric shape, only the border of this object is relevant. As the route runs along it, these landmarks are conceptualised by humans as line like objects. Area In the case of landmarks, which are conceptualised as areal entities, it is distinguished between landmarks belonging to the category 1 Element or to the category n Elements. 1 Element comprises all landmarks that identify a decision point by enclosing it, n Elements all landmarks around which the route is running. However, in both cases, the areal characteristic is important within the route instruction. The landmark is either more or less completely surrounded by the route or the landmark encloses a single decision point. Identified elements level On the Identified Elements level landmarks are distinguished by the type of route element (either decision point or route segment) they relate to. The different sub categories are explained here: 1 Element landmarks: DP or nondp 1 Element landmarks can be used either to identify a decision point or a route segment. Landmarks identifying a segment are not used for supporting making decisions in route following [34], but for allowing the travellers to assure, that they are still on the route. The landmarks located at a route segment are categorised as nondp. 1 Element landmarks located at decision points can either just identify the decision point or describe more specifically the action the traveller must perform at the decision point. They are categorised as DP. n Elements landmarks: identifying or not identifying the last DP n Elements landmarks are, in any case, used for identifying both decision points and route segments. They are usually found in route directions using spatial chunking, where a sequence of route elements is subsumed in one single instruction, a so called chunk. The end of a chunk can be identified by either the same n Elements landmark or by other techniques (cf. section 2.3). 23

24 24 Figure 2.7: Taxonomy for landmarks with a point like function located at a decision point. Identified Elements Level DP Object Class Level Turn Level Geometrical Level Point like Linear like Area like Point like Spatial Relational Level Street Name GSO Structure DP+ DP DP+ DP DP+ Linear like Area like at after before at after before at after before at after before at after before at after before DP CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS

25 2.2. USING LANDMARKS IN ROUTE DIRECTIONS Identified Elements Level nondp Object Class Level Turn Level Geometrical Level Point like Linear like Area like Spatial Relational Level pass cross pass through pass Figure 2.8: Taxonomy for landmarks with a point like function located at a route segment. a) b) Figure 2.9: a) not identifying last DP: Follow the river until you reach the church and turn right., b) identifying last DP: Follow the tram tracks till they end. 25

26 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS Hence, n Elements landmarks are categorised on this level by whether they are used for identifying the last decision point of the chunk (e.g. Follow the tram tracks till they end. ) or not identifying the last decision point (e.g. Follow the river until you reach the church. ) (cf. Fig. 2.9). Landmarks conceptualised as areas are not apt to identify the last decision point and are therefore, always categorised as not identifying the last decision point. Object class level This level is only relevant for point landmarks located at decision points (cf. 2.8). Here, it is distinguished between different categories of landmarks with a point like function: Street Name, Structure and general salient object (GSO). The category Street Name comprises the branches at a decision point indicated by their name, which may serve as a landmark. The category Structure is used for intersections that are salient enough to be a landmark (cf. section 2.1). All other objects that may function as a point landmark are grouped in the category GSO. It is necessary to distinguish between these three categories. Using them in route directions requires completely different descriptions for each type of landmark. For example, the information for identifying a house differs from the information describing the structure of an intersection. Turn level The Turn level comprises landmarks that are related to one particular decision point. In the case of n Elements landmarks, this decision point is the last intersection along the route the landmark is identifying, but only if the end is indicated by the landmark itself (cf. Identified Elements). At the identified decision point, the traveller has either to perform a directional change or to go straight. Hence, it is distinguished in the taxonomy between the categories DP +, where a directional change is required, and DP -, where the traveller has to go straight. (cf. Fig. 2.5). Geometrical Level On the Geometrical level, landmarks are categorised according to their geometry. The taxonomy contains categories for point like, linear like and area like landmarks (cf. Fig. 2.6, 2.8, 2.11). These categories are not based on the exact mathematical definition of the terms, but chosen according to their colloquial understanding. In a truly mathematical sense all landmarks would geometrically be areas in a 2 dimensional projection of the route and its surrounding environment. However, humans conceptualise some of them as point like (e.g. buildings), line like (e.g. rivers), or area like entities (e.g. forests). This is not influenced by their use in 26

27 Conceptual Level Line 27 Figure 2.10: Taxonomy of landmarks with a linear function. Identified Elements Level Object Class Level Turn Level Geometrical Level Spatial Relational Level Area like along not identify ing last DP Linear like along after Area like along Identifying last DP after Linear like along 2.2. USING LANDMARKS IN ROUTE DIRECTIONS

28 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS a route direction. The categorisation of a landmark depends, therefore, on the ratio of its width and its length and on its size proportional to the route itself and the context in which the route is used (e.g. indoor and outdoor). The transition between these categories is vague and cannot be easily defined in a formal way; it is often not clear whether a landmark is point like, linear like or area like. Heuristics may resolve this underspecification. Point like Point like landmarks usually cover a relatively small area and the difference between their width and their length is not very distinctive. These landmarks are only relevant for one single route element; the smallest and elementary units in giving route directions. Hence, they are conceptualised by cognitive agents in a point like manner. Examples for this category are single buildings such as a church, tower, etc. Linear like The length of landmarks, which are classified in this category, is usually distinctly larger than their width. Furthermore, they are often not only relevant for one single element of the route, but for several decision points and the interjacent segments. Since the linear extension of these landmarks is the distinctive feature, humans conceptualise them in a linear like manner. Linear like landmarks can be rivers, a row of houses or a rail track, for example. Area like The difference of the width and the length of an area like landmark is usually not significant. Here, the crucial point is, that these landmarks cover, in comparison to point like landmarks, a much larger area. This area can also contain streets, which are possibly even part of the route, or other landmarks. Since the distinctive characteristic of this type of landmarks is the covered area, humans conceptualise their geometry as area. Examples for this category are forests, parks or districts, whose distinctive feature is usually their spacious form. Spatial relational level The last level of the taxonomy is the Spatial Relational level. Here, the spatial relations between landmarks and action are differentiated. Depending on the functional role of the landmark in the described action, its geometry and its position a spatial term is associated with the landmark. It represents the appropriate spatial relation and reflects the mental conceptualisation. Spatial terms are, for example, Before, After, At as shown in Fig (cf. [19, 34]). These terms correspond not necessarily to natural language expressions. They are only used for labeling the spatial relation. Before, At and After 1 Element landmarks at a decision point can be situated Before the actual turning point, where the traveller has to change his 28

29 2.2. USING LANDMARKS IN ROUTE DIRECTIONS Root Level Landmarks Functional Level n Elements 1 Element Conceptual Level Area Area Identified Elements Level not identify ing last DP Object Class Level Turn Level DP DP+ Geometrical Level Area like Area like Area like Spatial Relational Level around in in Figure 2.11: Taxonomy for landmarks with an areal function. 29

30 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS direction, After it or not at one of the for route following functionally relevant branches at all [22]. In latter case, the spatial relation is referred to as At, whereas the other relations are called Before and After (cf. Fig. 2.12). a) b) c) Figure 2.12: Spatial relation between a decision point and a landmark: a) Landmark located Before the turning point, b) After the turning point and c) not located at functional relevant branch (At). pass and cross/through Route segments, at which a 1 Elements landmark is situated, can either Pass the landmark, Cross it or lead Through it. Accordingly, the categories are classified as Pass, Cross and Through (cf. Fig. 2.13). a) b) c) Figure 2.13: Spatial relation between a route segement and a landmark: a) Route Pass a landmark, b) Cross a landmark and c) Through a landmark. In For areal 1 Element landmarks the relation is always In, since the identified decision point is located within the area covered by the landmark. In all other cases landmarks with an area like geometry are categorised as line landmarks(cf. Fig c). Around The spatial relation areal landmarks and the route can have is called Around. Here, the course of the route encloses a large part of the area covered by the landmark (cf. Fig b). 30

31 2.2. USING LANDMARKS IN ROUTE DIRECTIONS a) b) c) Figure 2.14: a) Route Along a landmark, b) Around a landmark and c) a turn In a landmark. Along If the route follows the course or border of an areal landmark, the spatial relation is called Along. The course of the landmarks indicates the directional change at the related decision points (cf. Fig a) Landmarks at the start point Describing the first direction of a route is one of the most crucial tasks in giving route instructions. No previous orientation can be used for specifying the first action as travellers have not yet commenced their journey [31]. As a result of examining when and why visual landmarks are used by humans in giving route instructions, Michon and Denis found that humans very often try to solve the problem of orientating the traveller at the beginning of a route by using a landmark [31]. People describe the actions necessary for following the first route segment in relation to a landmark located in the closer environment of the start point Landmarks at the end point Michon and Denis also identified an increased usage of landmarks in human generated route directions at the end point [31]. Proceeding on the last segment of the route, the travellers have to be informed of the location of the destination along the current road. Travellers are currently orientated and the destination could be described in respect with their current position and orientation. However, humans use a salient object in the environment to describe relatively to it the location of the end point of the route How to describe landmarks? An aspect of the usage of landmarks, which is not the focus of this work, which information is required to describe a landmark in order to allow for an easy identification by the traveller. Especially the attempt to identify the necessary information and formalise them without regarding the context in which they are 31

32 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS used (e.g., who is the traveller? Which language is used?) is not sufficiently solved by current research. Some ideas can be drawn from the work of Brenner and Elias [1], who develops in her research approaches for the automatic extraction of landmarks from GIS data. In the GIS data sets objects like buildings or rivers, which can be used as landmarks are already classified. However, this are only first ideas, which are still ongoing research. 2.3 Subsuming route directions As experiments have shown, very detailed route directions, which provide all available information, not just necessary information, are rather confusing for the users (cf. [8]). Hence, most people giving route directions tend to reduce the amount of information. One method people use quite commonly in order to achieve this goal is to merge elementary route segments to higher order chunks. Automatically generated directions should try to abide by the way humans give route instructions (cf. [5]) or to be easily usable and understandable. Thus, it is useful to adopt the method of subsuming instructions in order to provide as much information as necessary and as few as possible. Two different approaches can be found in current research on combining several single route directions into one instruction, reducing the amount of information given. In the first approach, Klippel et al. focus on a process of conceptual organisation, the so call spatial chunking [24]. Their results are based on experiments with humans giving verbal route directions. They identify three different strategies people apply to reduce the amount of given instruction and formalises them for the use in the process of generating route directions automatically. The second approach proposed by Dale et al. [5], focuses on structuring route directions by imposing a hierarchy. Several instructions are combined to one super ordinate route direction, a so called chunk. The process is done recursively. Thereby, a hierarchy is built up, which allows the travellers to get an overview of the route and more detailed information by accessing the lower levels of this hierarchy Spatial chunking Klippel et al. [24] derive from experiments, in which people were asked to give route directions, how humans reduce the complexity of route directions by combining elementary route segments to higher order chunks. Based on the results of these experiments, they propose a formalism for integrating chunking in the automatic generation of route instructions. The aim of Klippel s approach is to reduce the number of instructions and thus the cognitive load. Especially decision points, that do not require a directional 32

33 2.3. SUBSUMING ROUTE DIRECTIONS change, are applicable for being chunked, since it is implicit for travellers to go straight at an intersection as long as they did not receive a different instruction. Besides that, several consecutive decision points, which require a similar directional change, can be subsumed in one single instruction. In order to formalise spatial chunking, Klippel distinguishes in his approach between two groups of decision points. All decision points, where the travellers have to change their direction, form a group that is called DP +. The decision points, where no change of the direction is necessary belong to a group, which is called DP -. For spatial chunking it is necessary to clearly indicate the last decision point of an instruction, because the travellers must be able to recognise, where a route direction ends and where the next starts. The users must be given enough information about the decision point, at which the subsumed sequence ends in order to allow for an unambiguous identificational. propose three different possibilities combining route segments, which are explained in the following. Numerical chunking The first possibility to combine elementary route elements to higher order chunks, is to provide the number of consecutive intersections belonging to the same group of decision points (DP + or DP - ) in order to describe the chunked route segment (cf. Fig. 2.15). Therefore, two cases are distinguished: either the decision points in the subsumed sequence belong all to the group DP + or, except of the last one, to the group DP Figure 2.15: Numerical chunking: Turn right at the third intersection (left picture) and Twice right (right picture). If the decision points in the chunk belong to the group DP - (except for the last one), following this sequence requires no turn until the traveller reaches the 33

34 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS last decision point of the segment, where finally a turn is necessary. This decision point is unambiguously indicated by providing the number of intersections without directional changes in this segment. It is implicit, that the traveller has to go straight at all intersections except the last. Therefore, the amount of the given information can be reduced by not mentioning it explicitly. Only for the last intersection of the chunk, the required action has to be described. A direction according to this type of chunking could be, for example, expressed by an instruction like: Turn right at the third intersection. In order to identify the decision point where the next turn is required, the travellers have to count the decision points they passes. After they passed the given number of decision points, which require no directional change, they have to turn at the next decision point. Since counting intersections becomes the more confusing for the travellers the more intersections are subsumed, the number of decision points combined in a chunk should be restricted. The second possibility for numerical chunking is the combination of several decision points, that require a similar directional change (cf. Fig and [34]). The turn direction at each decision point must be described with the same verbal expression. Such an instruction consists of an appropriate description of the turn the traveller has to perform at the decision points and the number of intersections that require such a turn. An instruction subsuming a sequence of decision points with a similar directional change is for example: Twice right. Here, the users has to count the number of equal turns. After they turned the necessary times, the instruction is completed and they can follow the next direction. Chunking based on structural landmarks Similar to numerical chunking, spatial chunking based on structural landmarks (cf. section 2.2) makes use of the possibility to subsume a sequence of intersections belonging to the group DP -, where the travellers have not to change their direction. The decision point, where the next directional change is necessary, is not identified by the number of intersections in the sequence of subsumed intersections, but by a structural landmark. On a sequence of decision points of the type DP - follows an intersection, which is unambiguously identifiable by its spatial structure. Possible spatial structures for chunking are T intersections, fork intersections and roundabouts (cf. section 2.1.). Therefore, such an instruction does not provide the actual number of passed intersections. It just tells 34

35 2.3. SUBSUMING ROUTE DIRECTIONS the travellers to go straight until they reach an intersection with a certain spatial structure. An example for spatial chunking, which uses a structure as a landmark for the identification of the last decision point of a chunked sequence, is: Turn right where the road dead ends. In this case the intersection is a T intersection. This type of intersection is especially apt for this kind of spatial chunking, since it requires in any case a directional change. The intersection does not allow for going straight, but forces the travellers to perform a directional change. Thus, the travellers must follow the road, going straight at each of the decision points until they reach a T intersection, which forces them to change their direction Figure 2.16: Chunking based on structural landmarks: Turn right where the road dead ends. Chunking based on point landmarks In this and the next section concepts of landmarks discussed in section 2.2 are combined with Klippel s approach. Klippel does not mention the different categories explicitly, although he uses them in different types of chunking. Besides the structure of intersections other point landmarks can be used for identifying unambiguously the last decision point. There, the travellers have to change their direction after passing the chunked sequence of intersections without directional change The usage of point landmarks is similar to chunking on the basis of structural landmarks. For indicating the last decision point of a chunk the landmark has to be unambiguously identifiable on the current segment of the route. The intersections which have to be passed before reaching the landmark must not require any directional change, so they have to belong to the group DP -. An example for using a point like landmark for spatial chunking, is the route direction: 35

36 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS Turn right after the church Figure 2.17: Chunking using a point landmark: Turn right after the church. The landmark which is used for identifying the last intersection of the segment is in this case a church (cf. 2.17). It is situated directly at the intersection where the traveller has to turn. Here, it does not only indicate the decision point, but also is used for describing the action itself. The travellers continues going straight at each intersection they reach, until they arrive at an intersection with a church. There, they perform the described turn. Chunking based on line landmarks Richter and Klippel introduce in their article A Model for Context Specific Route Directions [34], which extends Klippel et al. s [24] ideas, an additional alternative for spatial chunking using line landmarks. For this kind of chunking route directions, the directional changes the travellers have to perform are defined by the course of the landmark, they have to follow. That means, that unlike for the previously mentioned types of spatial chunking, the decision points passed while travelling along the linear object do not necessarily belong to either group DP + or DP -. The problem with this kind of spatial chunking is, that it does not specify the end of the segment. Thus, it is not clear, where the travellers have to leave the course of the linear landmark, they are following. Hence, it is necessary to extend the instruction by a stop criterion, as described in the section 2.2, which indicates the decision point where the route stops leading along the course the line landmark. 36

37 2.3. SUBSUMING ROUTE DIRECTIONS A common example is to use the course of a river for describing the course of the route. A direction combining all decision points along this river could look like this: Follow the river Figure 2.18: Chunking using a line landmark: Follow the river. In order to avoid the problem that the travellers do not know how long they have to follow the linear landmark, the route instruction could be extended to the following direction: Follow the river until you reach the bridge and then turn right. The end of the segment leading along the river is indicated by a point landmark, in this case a bridge. Of course, the used landmark must identify the last decision point at the course of the line landmark unambiguously Segmenting route directions In their article CORAL: Using Natural Language Generation for Navigational Assistance [5] Dale et al. describe a way to generate textual route directions based on GIS data using natural language generation techniques. One of the main concerns in this article is to decrease the cognitive load on the user and to increase the memorability of the route directions. Therefore, in this approach, path and turn instructions are grouped in higher level entities which are called segments, and structured in a hierarchy. The hierarchy is built up recursively on the elementary directions by generating segments, which combine several elementary instructions, and give a summarising description for each of them. The resulting segments of paths and decision points can even contain major turns. Not only unimportant or obvious instructions are hidden, but longer 37

38 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS parts of the route summarised, as not to distract a user who is familiar with the environment with too detailed information. The information, which is not included in the summarised description of a segment, can still be accessed by the users by zooming in. That means, they can unfold the direction describing a segment in order to get the instructions for the subsumed subsegments and paths. Structuring route directions An important part in Dale at al. s approach is to build a hierarchy on route directions and structure them, in order to enable the users to access instructions with different levels of detail according to their knowledge about the environment. For structuring route directions Dale based his approach on a pattern which splits up the description of a route in three main segments: start, middle, end. Usually these three main segments initially lead the user to a main thoroughfare or a major road (start segment), describe the travelling along this road (middle segment) and explain how to reach the final destination after leaving the major road (end segment). The three single segments contain other segments, which summarise again other segments or elementary route elements, so that a hierarchy is built up on the route directions. This pattern can of course not be applied for every possible route. When examining several routes Dale found, many different types of this pattern exist, and start, middle and end segment interact in a complex manner. Thus, the approach does not necessarily structure each route by exactly these three features, but uses the pattern as a heuristic for his automatic generated route directions. The better the structure approximated the pattern, the better the route directions were. For breaking the route in segments Dale developed two different strategies: Landmark based segmentation and path based segmentation. Landmark based segmentation The first strategy uses landmarks to indicate the end of a segment. A landmark located at a decision point delimits a segment of the route. Therefore, the travellers will know whether they have reached that point and thus, how far they have progressed in following the route. Hence, all route segments and all decision points the traveller passes on the way from the beginning of such a part of the route to the landmark are summarised in a subsuming instruction. If the users are familiar with the landmark, which is described in the summarised instruction, they can directly travel to it without reading the exact directions to get there. Otherwise they can still access the more detailed instructions, which explain the route to get to the end of the current segment indicated by the landmark. 38

39 2.3. SUBSUMING ROUTE DIRECTIONS Path based segmentation Besides segmenting route directions based on landmarks, Dale also uses different characteristics of paths and turns to spilt the route in several parts. Each part is then represented by one instruction. The segmentation process in this case is based on three features: The road status hierarchy, the path length and the turn topology. Road status hierarchy Roads in a street network can usually be classified in different categories according to their level in a street hierarchy. Consecutive paths with same or similar level in the hierarchy are likely perceived as higher level entity and thus, can be summarised in a single segment. Path length The path length itself is not directly used as a criterion for subsuming instructions. If there is more than one option, this information may help in some cases to decide which segment might be a candidate for the middle segment. Turn typology Another possibility to indicate the border of a segment is to describe it with a very salient turn. Intersections, which require a careful navigation (with competing branches) or which can be easily identified (T intersections), can be used for this purpose Extending and combining Klippel s and Dale s approaches In the following section both articles will be compared and aspects of both combined in one single approach. The result will function as a basis for combining route instructions to a subsuming direction later in this work. Comparison of the approaches Both approaches deal with the question, how can the amount of information given in route direction be reduced, in order to provide the navigators only with the necessary information. Although they try to answer a similar question, both approaches use a different way to solve the problem. Klippel s approach does not recursively combine route directions. Its focus is on reducing the actual number of instructions by subsuming route directions, which are obvious or unimportant. Even though it produces a flat two layered hierarchy, this is not its main purpose. It aims not on reducing instructions for a user who might be familiar with the environment, but rather on subsume decision points, which do not necessarily have to be mentioned. In contrast, Dale s approach tries to make route directions simpler for travellers who are familiar with the environment. By introducing a hierarchy, where the 39

40 CHAPTER 2. COGNITIVE ERGONOMIC ROUTE DIRECTIONS number of instructions between the different levels is reduced, and which can be, if necessary, unfolded, it offers the users the possibility to only access the instructions of the level of detail, they really need. The differences between both approaches are especially obvious, if the techniques, which are used to generate higher order chunks, are compared. In Klippel s approach elements, which are used to indicate a chunk (e.g., general landmarks or the spatial structure of a intersection) have to be salient and easily recognisable only at the related part of the route. The route, which has to be followed to reach them, is implicitly given in the direction. Dale uses for his segmentation process features of paths and decision points, which are especially helpful, if the navigators are familiar with the environment (e.g. they already know major roads or landmarks). The description of the route to get there is quite coarse and only sufficient if the users already have some knowledge about it. If it is a new environment for him, they have to access a lower level of the hierarchy to get helpful and sufficient directions. Combination of the approaches Klippel s and Dale s approaches focus on different aspects of segmenting route directions. For the further usage in this work, the main characteristics of both will be combined to one single approach, in order to integrate higher order chunks and a more cognitive ergonomic structure in route directions. Therefore, Dale s hierarchy is used in combination with Klippel s chunking approach, which is extended by Dale s additional chunking possibilities. Since Klippel s approach offers only a flat hierarchy with two levels, Dale s idea of building up the hierarchy recursively is used. Structuring the route according to Dale s pattern in a start, a middle and an end segment, is not taken on explicitly, but can still be implemented with the chosen techniques. This has been done, because Dale developed his approach for routes in an Australian street network and it is not yet clear, if it can be easily adopted for a different environment like, for example, a street network in an old European town. For segmenting the road, two different cases can be distinguished. Directions can be chunked on the level of elementary route directions and on a higher level, where already subsuming segments are combined. For combining elementary route elements, Klippel s approach offers much more possibilities and includes most of the combining possibilities Dale proposes. So Klippel s ideas are used to reduce the directions by unimportant or obvious instructions (e.g., for decision points without directional change). Because most of the chunking techniques proposed by Klippel are designed for subsuming elementary route elements (e.g., numerical chunking), they are not adequate for creating the third or an even a higher level of the hierarchy. Therefore, mainly Dale s techniques for segmenting the route are used on higher levels. 40

41 2.3. SUBSUMING ROUTE DIRECTIONS Integration of the taxonomy of landmarks Since the concept of landmarks used in Klippel s definition of spatial chunking and Dale s approach to segment and structure route directions does not exactly accord with the concept of landmarks in this work (cf. section 2.2). Some changes are proposed, which do not affect the general idea of both approaches, but combine them with the taxonomy of landmarks [23]. In the taxonomy of landmarks, on which this work is based, general point landmarks as well as the structure of an intersection, which are used as turn topology by Dale, are regarded as point landmarks. Even areal and linear landmarks can have the function of a point landmark. According to the taxonomy, it will distinguish between chunking based on line and point landmarks. Akin to Klippel s approach structural landmarks will be treated separately. 41

42

43 3 Analysis of current navigation services Besides the theoretical, scientific approaches, many commercial navigation services providing route directions exist. In the following chapter the services Map24.com Mapblast.com Mapquest.com Maporama.com are analysed and an overview of commercial navigation systems on the Internet are given. The focus is on, how far they provide route directions according to the previously discussed ideas of cognitive ergonomic route directions. To examine the integration of landmarks in the provided directions a fifth service is used since the other services do not provide landmarks. 3.1 Making direction concepts more precise Section 2.1 discusses how route directions should deal with difficult spatial situations in order to give the traveller a precise and unambiguous instruction. This section will examine, how navigation services deal with these situations. This is shown by three examples with different spatial situations and types of intersections generated by different web based navigation services Example: Fork intersection Figure 3.1 illustrates the spatial situation at a fork intersection in Dinkelsbühl, Germany. Following the road Marktplatz coming from East, the traveller arrives at a decision point where the current road splits up into two branches. It is hard to decide which of the two possible branches is the extension of the street Marktplatz, since both have a similar size and none of them have the street name Marktplatz. All these characteristics can be used for generating a precise and not too complex instruction describing the required action at this decision point. By naming 43

44 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES Figure 3.1: Spatial situation at a fork intersection. In the left part the traveller has to turn right, in the right part left. (Modified picture from from June 2005). the type of the intersection as a fork intersection, the travellers could easily identify the intersection and would have had a rough impression of the spatial situation they had to expect. In combination with naming the type of the intersection, it would be sufficient to give as turn direction the instruction to take the left or right branch. Therefore, a route direction for this situation could be, for example: Follow the road Marktplatz and turn left at the fork intersection into Segringer Strasse. Since this example could not be produced by only the other three services have been examined. Figure 3.2 show a tabular with the verbal directions generated for a left and right turn at the intersection shown in figure 3.1. None of the examined navigation services uses the spatial structure of the intersection to make its identification easier. The only information about the spatial situation the traveller is provided with is a map depicting the street network. The spatial structure is also not included in the descriptions of the turn. On the basis of this example, it is difficult to make a statement about the underlying direction model which is used by the navigation service for generating the turn direction. However, the interpretation of the left turn as straightforward by might indicate the use of a model with homogeneous sectors, which leads in this case according to Klippel et al. [24] to a less cognitive ergonomic instruction. Also, to describe this left turn just as change of road names as done by is highly questionable. The services and support their verbal instructions not only by a map showing the calculated route, but also by small 44

45 3.1. MAKING DIRECTION CONCEPTS MORE PRECISE RIGHT TURN LEFT TURN Leave the Marktplatz and turn right into the Street Weinmarkt. Leave the Marktplatz and head straightforward onto the Segringer Straße. Turn SLIGHT RIGHT onto WEINMARKT. Turn SLIGHT LEFT onto SEGRINGER STRASSE. Bear RIGHT (North-West) onto Weinmarkt Road name changes to Segringer Straße Figure 3.2: Verbal direction for the fork intersection in Fig. 3.1 provided by three different navigation services in June

46 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES icon depicting an arrow in the direction of the turn (cf. Fig. 3.3). Since they do not add any additional information to the verbal instruction, any additional conclusions about the direction model used cannot be drawn. mapquest.com map24.com Right turn Left turn Figure 3.3: Icons provided by and for the intersection in figure Example: Competing branches In the second example that is used for analysing how current navigation services deal with difficult and ambiguous spatial situations, the traveller arrives at a complex intersection in Hofheim in Unterfranken, which has five branches. One of them are on the travellers left-hand side, one is straight (depending on the implementation of the direction model discussed in section 2.1) and two are on their right-hand side. The fifth is the one on which the traveller is approaching the decision point. For this example the route directions generated by three of the navigation services for the two possibilities to turn right are compared. Figure 3.4 shows the spatial situation at this intersection. The road on which the traveller is approaching the intersection is marked with a red arrow pointing in the travel direction. The difficulty in this example is that it is not sufficient to instruct the traveller to turn right, as it was the case in the example with the fork intersection. The outgoing branch has to be explicitly identified. It must avoid that the branch is confused with the other possibility to turn right. Otherwise, the instruction will become ambiguous. A possible solution for this problem would be, as outlined in section 2.1, instead of providing only a simple turn direction, to combine the direction with an ordering concept. Additionally, preparing the traveller for the situation by 46

47 3.1. MAKING DIRECTION CONCEPTS MORE PRECISE Ostheimer Str. Ruegheimer Str. Ringstr. Poststr. Obere Torstr. Figure 3.4: Intersection with competing branches on the left as well as on the right side of the intersection. (Modified picture from from June 2005). naming the type of the intersection is also helpful. A route direction for directing the traveller on the Poststrasse could be for example: Take the first branch on your right onto the Poststrasse. Analysing the route directions generated by the three examined navigation services (cf. Fig. 3.5) shows that none of them are able to provided the traveller with unambiguous and precise instructions. The services and do not differentiate between the two different right turns at all. In both cases they give the traveller the instruction turn right. On the other hand, at least attempts to distinguish between both situations. However, the instructions turn right and bear right in combination with the orientation of the turn is still not sufficient. Additionally to a map depicting the route and the verbal instructions, map24.com and provide the traveller with small pictograms of arrows in the corresponding turn direction. The pictures supporting the instructions of simply depict in both case an arrow to the right according to the imprecise directions. Since both turns are not a classical right turn and since offers in some cases pictograms with a slight right pointing arrow, this is a bit astonishing. Drawing a conclusion on the underlying direction model is, therefore, not possible. However, the pictograms provided by differentiate between both cases and depict appropriately a slight right and a sharp right 47

48 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES Poststrasse Rügheimer Strasse Leave the Obere Torstraße and turn right into the Poststraße. Leave the Obere Torstraße and turn right into the Rügheimer Straße. Turn right, follow Poststrasse for 134 m Turn right, follow St2275 for 2.5 km Turn RIGHT (South) onto Obere Torstraße, then immediately turn RIGHT (North-West) onto ST2281 (Poststraße) Turn RIGHT (South) onto Obere Torstraße, then immediately bear RIGHT (South-West) onto ST2275 (Rügheimer Straße) Figure 3.5: Verbal direction for the intersection with competing branches in Fig. 3.4 provided by three different navigation services in June Described is a right turn into Poststrasse (left) and a right turn into Rügheimer Strasse (right). 48

49 3.1. MAKING DIRECTION CONCEPTS MORE PRECISE pointing arrow. Despite the graphical direction not matching the verbal instruction, it clarifies the situation a bit for the traveller. On which direction model the generated direction are based cannot be decided with this example, but is suggestive of to a homogeneous sector model Example: Roundabout The last example shows how the tested services deal with roundabouts. In this case the decision point is a large roundabout in Würzburg, where the traveller has to take the fifth exit (cf. Fig. 3.6). Again naming the structure of the intersection is very useful information for the traveller. In the case of a large roundabout, the usual direction like left or straight are rather confusing and ambiguous. Therefore, the usage of an ordering concept helps to generate a precise instruction, which is easy for traveller to follow. An example for such an instruction is: Take at the roundabout the 5th exit onto Martin-Luther-Strasse. Figure 3.6: Spatial situation at a roundabout (Modified picture from map24.com from June 2005). Indeed three of the five examined navigation services (cf. Fig. 3.7) generate a route instruction that is quite similar to the above suggested directions. They name the structure and direct the traveller to the correct exit by using an ordering concept and the street name. Only differs from this. It also names the type of the intersections, but uses instead of an ordering concept, a combination of the street name of the exit and the distance the traveller should cover along the roundabout. This might be somehow understandable since the roundabout in this example is quite large, but generates 49

50 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES Enter the roundabout Berliner Platz and leave at the 5. exit onto the Martin-Luther-Straße. 6: Follow Berliner Platz for 150 m 7: Turn right, follow the roundabout Berliner Platz for 207 m 8: Turn right, follow Martin-Luther-Strasse for 270 m At roundabout, take the FIFTH exit onto Martin-Luther-Straße Enter next roundabout and take 5th exit onto MARTIN-LUTHER- STRASSE. Figure 3.7: Verbal direction for the roundabout in Fig. 3.6 provided by four different navigation services in June

51 3.2. LANDMARKS IN NAVIGATION SERVICES similar route directions for smaller roundabouts, where the traveller has only a few meters to cover. 3.2 Landmarks in navigation services The examined commercial navigation services were also tested to which extent they make use of landmarks. In this case, landmarks means anything salient used to identify a decision point or route segment, which is not a street name (that is used by all of the services) or a roundabout as discussed in the previous section. As a result of this examination, landmarks are not commonly used in current navigation services. All four services generate route directions without integrating landmarks; typical landmarks such as salient buildings. In order to present at least one example of route directions containing landmarks, additionally the navigation service stadtplaene.klicktel.de was analysed. The instructions it provides are only available in German. This is also the reason, why it is not used for examination of the other aspects of cognitive ergonomic route directions. The absence of landmarks in most of the automatic generated route directions can maybe be explained with the lack of sufficient data about landmarks. The typically used street data does not contain an ample amount of information for describing unambiguously a landmark. Additional reliable data that would solve this problem, is difficult to acquire and expensive and therefore not an option for most of the commercial navigation services (cf. [1]) Landmarks in stadtplaene.klicktel.de Stadtplaene.klicktel.de is a German navigation service, that provides route directions including maps depicting the route and the surrounding environment and verbal instruction of the required action. Both are enhanced with landmarks. The provided route directions are only available in German. An instruction generated by stadtplaene.klicktel.de consists usually of two parts. The first describes an action, that has to be performed at a decision point, the second describes the following segment. In the generated route instructions mainly buildings with a commercial purpose (for example petrol stations or car dealers) are used as point landmarks. They are located at intersections and shall support the identification of the decision points and specify the required action. An example for route directions generated by klicktel.stadtplaene.de using landmarks is shown in figure 3.8 (a map of the spatial situation and an excerpt from the route directions, both provided by klicktel.stadtplaene.de) and 3.9 (a schematic map of the relevant part of the route in order to clarify the spatial 51

52 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES stadtplaene.klicktel.de 3: Links abbiegen auf Dieselstr., Straßenverlauf folgen für 0.10 km 4: Vor BMW rechts abbiegen auf Zeiler Str. (B26), Straßenverlauf folgen für 0.12 km 5: Nach Walther links abbiegen auf Am Wasserwerk, Straßenverlauf folgen für 0.16 km Figure 3.8: Map and verbal directions for route using point landmarks provided by klicktel.stadtplaene.de in December situation). The route leading through Hassfurt contains two turns located at landmarks. Instruction number 4 and 5 describe both an action at a decision point specified by a point landmark. In both cases, the actual location of the turning point is described by its spatial relation to the landmark (before and after). The landmarks themselves are identified in the instructions; since both have commercial purpose, by either their name (Walther) without informing the user that this is a petrol station, or the name of brand of the product (BMW), which is sold in the particular shop without specifying that it is car dealer. Other characteristics are not described. The integration of point landmarks in route directions gives the travellers more possibilities to reassure, that they are still following the correct route. Landmarks, if chosen carefully, are usually easier to spot than street signs, which are used for a similar purpose in the other examined services. Therefore, the instructions provided by klicktel.stadtplaene.de are closer to what this work considers as cognitive ergonomic. The service even integrates the landmarks in the description of the required action. However, there are still enough possibilities to enhance this feature. The landmarks used are hardly described; this makes is it difficult for the traveller to identify the landmark itself. Providing the name of the company using the building is certainly not enough. Additionally, all the 52

53 3.3. SUBSUMING ROUTE DIRECTIONS Walther Dieselstrasse Zeiler Strasse Zeiler Strasse Am Wasserwerk BMW Am Wasserwerk Figure 3.9: Schematic diagram of spatial situation depicted in figure 3.8. other types of landmarks described in section 2.2 should be integrated in order to make the route directions more cognitive ergonomic. 3.3 Subsuming route directions This section it will examines how far chunking of route directions discussed in section 2.3 is implemented by current navigation services. Additionally, street name chunking, another method of subsuming several instructions that was not mentioned before, will be regarded since it can be found in almost all of today s navigation services Street name chunking A common approach used by commercial navigation services to combine several route segments to one single route direction is the so called street name chunking. The name of the street the user has to follow indicates the current route segment. Only decision points, at which the street name changes or the traveller has to leave the current road, are mentioned in the directions for the described segment. Other decision points are omitted. Since street names are used in this context similar to line landmarks, chunking based on them requires to indicate unambiguously the end of the segment by providing additional information, as discussed in section 2.3 about spatial chunking along linear landmarks. So the traveller is able to identify the last decision point 53

54 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES of the chunk and can complete the described action. In order to do this current navigation services describe the intersection, at which the traveller has to enter the next road, by providing the name of this next street in combination with the distance that has to be covered on the segment. Other types of point landmarks, which would be also appropriate and possibly more helpful for identifying the last decision point of the segment, are not used in the analysed navigation services. The implementation of street name based chunking in the analysed navigation services do not offer the user to zoom in the subsumed instructions. If decision points are chunked to one segment, the traveller has no possibility to dissolve a higher order route direction in order to get more detailed instructions about the single intersections. 2: Leave Zur Munte and turn left into Parkallee. Stay on for 1.34 km. 3: Leave Parkallee and turn left into Schwachhauser Ring. Stay on for 252 m. 2: Turn LEFT (South) onto Parkallee 3: Turn LEFT (East) onto Local roads Figure 3.10: A map provided by and verbal directions provided by and using street name chunking (from June 2005). An example for chunking based on a street name is shown in figure The described route is located in Bremen, Germany. The services and combine all decision points after entering Parkallee including the intersection where the traveller has to turn on Schwachhauser Ring, to one single instruction. The decision point, where the traveller has to leave the Parkallee is described in a separate instruction. For indicating the intersection 54

55 3.3. SUBSUMING ROUTE DIRECTIONS Figure 3.11: Map taken from in June 2005 depicting the route using road hierarchy chunking described in Fig the analysed navigation services provide the name of the street the traveller has to enter and given in the previous instruction, the distance that has to be covered Road hierarchy chunking Another chunking method which can be found in the analysed services, is based on the position of a segment in the road hierarchy. The way this is used by the services is quite similar to the street name chunking described before. Often roads have an additional name, which refers to its position of the road in the administrative street level hierarchy (e.g., B75 in Fig and 3.12). Usually this name covers several streets with different normal street names. This superordinate name is used for the road hierarchy chunking in the same way as the normal street names in the street name based chunking. Therefore, pure road hierarchy chunking cannot be found in one of the analysed navigation services. But since these superordinate names also provide information about the level of the street in the road hierarchy, it can be referred to as road hierarchy chunking. According to street name chunking, the end of a segment has to be indicated with additional information so that the travellers can easily identify the decision point where they have to leave the current road. This could be done by any kind of landmark with a point-like function. Again the analysed navigation services use a combination of the distance of the previous segment and the street name of the road to enter for the description of the last intersection of the chunk. An example for road hierarchy chunking provided by two of the analysed services is shown in figure 3.11 and figure The streets Osterdeich, Tiefer, Martinistraße, Wilhelm-Kaisen-Brücke and Friedrich-Ebert-Straße in Bremen, Germany belong all to a superordinate road which has the administrative name 55

56 CHAPTER 3. ANALYSIS OF CURRENT NAVIGATION SERVICES 3: Turn left, follow B75 for 3.5 km until BREMEN. 4: Turn right, follow Pappelstrasse for 58 m 5: Turn RIGHT onto OSTERDEICH/B75. Continue to follow B75. 6: Turn LEFT onto BALGEBRÜCKSTRASSE/B75. Continue to follow B75. 7: Turn RIGHT onto ERLENSTRASSE. Figure 3.12: Verbal directions describing a route (cf. Fig. 3.11) using road hierarchy chunking from June B75. This name indicates the level of the road in the administrative street-level hierarchy. Since travelling along the described route requires to follow a long distance on the B75, the services use this superordinate name for generating one long segment. The instruction provided by covers several usual streets with different names and even a major turn, but it never leaves the B75. Whereas splits the same segment at the major turn in two single route directions. The end of the segment is in both cases again identified by the name of the next road and the distance of the previous segment. 3.4 Summary of results As the examples in this chapter have shown, the aspects of cognitive ergonomic route directions discussed in chapter 2 can hardly be found in current navigation services. As soon as the spatial situation at an intersection becomes difficult to describe, the services fail in giving precise and unambiguous instructions. The companies providing these services are probably not aware of this problem, since solving this requires only small adaptions of the services. Current navigation services offer the possibility of reducing the complexity of route directions only to a very limited extent. The reason, why street name chunk- 56

57 3.4. SUMMARY OF RESULTS ing and (in a very similar way) road hierarchy chunking are used, is probably, that the necessary information is part of the GIS data the navigation services are based on and therefore easily accessible and not causing additional costs. However, it is problematic that the data sets do not contain any information about the salience of this information for the traveller navigating in a real environment. Signs with street names are not necessarily available at each intersection or not visible from each position. Thus, this information is not in any case reliable and helpful for navigation purposes. One of the reasons why other types of chunking cannot be found in any of the services, is the lack of the necessary elements for indicating the end of a segment such as the landmarks. Without landmarks, many chunking techniques cannot be implemented. The only possibility, which is not used even though it is easily available, is chunking based on the spatial structure of intersections. The necessary information can be extracted from the underlying data set without additional costs. Therefore, it is a possibility which could be easily used for chunking by commercial navigation services in order to make route directions more cognitive ergonomic (cf. [22]). However, not only for spatial chunking are landmarks a crucial part of cognitive ergonomic route directions. The integration of landmarks would help travellers to identify single parts of the route and to make the described actions easier to follow. Therefore, the question arises, why landmarks are not used commonly by navigation services? The main reason can probably be found in the lack of data about landmarks. It is very costly and difficult to get reliable information about landmarks. Since this problem is not solved sufficiently, other commercial navigation services will hardly implement route directions using landmarks. 57

58

59 4 OpenLS This work aims on integrating cognitive ergonomic aspects in automatically generated route directions. The Open Location Services specification [30, 2] offers an open interface to a location based server. Extending this by the aspects discussed in chapter 2 specifies a system providing automatically generated route directions. In this chapter the OpenLS specification and its functionality is outlined and the potential of giving route directions is discussed. 4.1 The OpenLS framework Location based services are usually provided over a network, which offer users information depending on their current location. The functionalities available are primarily designed to meet the requirements of mobile devices, which are assumed to be used for accessing the services. Examples for these services are providing the address of a user s current location (reverse geocode services), points of interest in the closer environment (directory services) or navigation and routing information (route or navigation services). Location based services are often regarded as one of the main applications in mobile networks. Therefore, the Open GIS Consortium (OGC) proposed an implementation specification, which describes the Open Location Services (OpenLS), also known as the GeoMobility Server (GMS). This standard specifies an open platform for location based services. The Server implementing this platform according to the specification can be accessed by any client that supports OpenLS. The OpenLS specification describes the basic services of a GMS (directory service, gateway service, location utility service, presentation service, route service), their basic functionality, the communication between client and server, the abstract data types (ADT) and the relationship of OpenLS with respect to specifications and standards. The provided services are described in section 4.3. The OpenLS standard consists of a set of specifications of interfaces (defined as XML schemas), which determine the access to the basic services of such a server and the abstract data types used in the documents exchanged in the communication between server and client. That means, OpenLS defines primarily the interaction between client and server (request and response schemas) and the format in which the transfered data is encoded. By specifying this, the basic functionality which a server implementing the OpenLS Specification has to offer 59

60 CHAPTER 4. OPENLS Core Network GeoMobility Server OpenLS based Applications Service Provider Portal / Service Platform Concierge Personal Navigator Tracker... OpenLS Authentication Billing... Position Determination Equipment (GMLC / MPC) 3rd party Server LIF API OpenLS OpenLS Core Services Route Service Gateway Service Presentation Service Directory Service OpenLS OpenLS Applications residing on Mobile Terminals and Desktops OpenLS Services OpenLS Geocode / Reverse Geocode Service OpenLS Navigation Service Location Content OGC Interfaces OGC Interfaces Location Content Road Networks Navigation Information Traffic Information Directories Addresses Maps Figure 4.1: Structure of a GeoMobility server. is implicitly defined. Since May 2005 OpenLS is available in the version 1.1, which has the status final. Recently the OGC has formed a group, which will develop the next version of the OpenLS specification Top-level architecture The core of the OpenLS specification is the GeoMobility server. A GMS offers location based services for other service providers and client applications. For generating the provided content, an OpenLS server might also access location based services offered by third parties. Figure 4.1 shows the structure of a GMS. In the following section the relationship between a GMS with respect to the other elements of a LBS architecture is described. GeoMobility server The main function of a GeoMobility Server is to provide the core services defined in the OpenLS specification. They offer the basic functionality of a GMS. Therefore, the central part of a GMS is the application providing these services. A GMS has to implement all five core services. 60

61 4.1. THE OPENLS FRAMEWORK The location content necessary for processing the incoming requests, can reside on the GMS itself or on a separate server. In both cases, this information is accessed via other interfaces developed by the OGC. Additionally, to the basic functionality of the OpenLS core services, a GMS can run OpenLS based applications, which provide additional services (e.g., service management functions). The communication between the core services and the OpenLS based applications has to be implemented according to the OpenLS specification. Providing services for users and other service providers The services provided by the GMS can be accessed directly by applications running on the users mobile terminal or desktop PC, as well as by portal and service platforms. Besides arranging the access of the user s application to the information provided by the GMS, these portal and service platforms can also be responsible for other functionalities (e.g., authentication and billing). They may reside on the same physical server. Besides the location content residing on the GMS itself and the OpenLS services, a GMS can provide access to services by third parties and use third parties content for generating the content of its own services. An example for third party services a GMS uses is the determination of the position of a mobile terminal. A GMS accesses a server providing position determination equipment. Such a server is called Gateway Mobile Location Center (GMLC) or Mobile Positioning Center (MPC) XML based languages in OpenLS The communication between client and server is realised by exchanging XML based documents. Also the internal access of the location content, the communication between the core services, the OpenLS based applications and large parts of the access of third party contents and services are based on documents encoded in XML. The OpenLS specification itself defines XML for Location Services (XLS), a XML-based markup language, for accessing the OpenLS services. Additional XML-based languages are used for other purposes (e.g., encoding geographic data) which are required for generating the offered content. In the following section XLS and the Geography Markup Language (GML) used for encoding geographic data are shortly discussed. XML for location services The main part of the OpenLS specification is the definition of the XML-based markup language XML for Location Services (XLS). The documents defined as 61

62 CHAPTER 4. OPENLS request and response schemas and exchanged in communication between client and an GMS are encoded in XLS. XLS is a markup language defined by a XML schema. It defines the structure and appearance of the XML-documents, which are transfered as requests and responses for the client/server interaction and it specifies the abstract data types (ADT) (e.g., there is an ADT for an address, a location, a route) used by the OpenLS services for encoding information. The ADTs representing route directions are later discussed in detail and extended by cognitive ergonomic aspect. Geography markup language The Geography Markup Language (GML) is also a XML based language in compliance with ISO [17] developed by the OGC [4]. It is used for modelling, transport, and storage of geographic information. Since GML is an open standard, it supports the interoperable use of geospatial information. The OpenLS specification uses GML for the encoding of geographic information. In a XLSdocument all geospatial data is encoded in GML The OpenLS services The basic service framework of a GeoMobility Server is formed by the five so called core services. These services are described in [30]. In an additional document [2], a sixth service, the Navigation Service, is specified. This Navigation Service does not belong to the core services. In the following section, the functionality of these service is briefly described. Core services Part 1: Directory Service The Directory Service offers access to an online directory (e.g. Yellow Pages) to find the location of a specific (Pinpoint Directory Service) or nearest (Proximity Directory Service) place, product or service. The subscribers specify the place, product or service they are seeking by entering identifiers and a position. The request must also contain the information the users are looking for, either a specific or the nearest place. If they want to access a nearest or a specific location additionally a position has to be encoded in the request. Furthermore, the directory type may also be specified. The server returns one or more responses to a query. Part 2: Gateway Service This service is an interface between a GMS and a Location Server (GMLC/MPC), which has access to the current position of mobile devices. The Gateway Service enables the subscribers to request the location of their and/or other mobile devices. This service plays a central 62

63 4.1. THE OPENLS FRAMEWORK role in the core services, since the current position of a mobile device is essential for most of the other services. Part 3: Location Utility Service The Location Utility Service has two main functions. It can act either as Geocode or as reverse Geocode. As Geocode, the service provides the position according to the requested description given a place, street address or postal code. It also completes information missing in the given description. As reverse Geocode it returns the complete description of a feature location (place name, street address, postal code) to a given position. Part 4: Presentation Service The Presentation Service renders geographic information which can be displayed on a mobile terminal. It can be used by all other services in order to provide the rendered information in their response to a subscriber s request. Therefore, the presentation service offers maps with or without overlays depicting additional information. For example, it is possible to render a map with an overlay visualising a route calculated by the Route Service or by the Navigation Service. Part 5: Route Service The Route Service provides information necessary for following a requested route. The subscriber has to specify a start and an end point of a route and may optionally indicate additional parameters such as way points, route preferences (e.g., fastest, shortest, most scenic, etc.) or the mode of transport (car, public transport, etc). The response provided by the Route Service on a route request contains, for example, a map including an overlay depicting the calculated route, additional information about the route such as the estimated travel time and its length, or verbal route directions. Navigation service Part 6: Navigation Service The Navigation Service is an enhanced version of the Route Service. It is not part of the services of the OpenLS specification and is described in a separate document [2]. It supports the same parameters as the Route Service and thus, offers the same functionality. Additionally, it extends the Route Service by adding special parameters for navigation purposes. This allows the client to provide the user with more detailed and elaborate route directions. It introduces a special data structure for route directions. The information encoded in such ADTs can be converted by OpenLS based applications for more specific and appropriate route directions. 63

64 CHAPTER 4. OPENLS 4.2 Route directions with OpenLS The OpenLS specification offers two different possibilities for providing route directions. The first is based only on verbal instructions encoded as simple strings and supported by both services dealing with routes, namely the Route Service and the Navigation Service. The second, which is only part of the Navigation Service, provides for each instruction a complex object offering the client the possibility of generating directions according to the user s preferences. In the following section, both methods are described in greater detail and their advantages and disadvantages are discussed Route directions in the route service The functionality of the Route Service focuses on calculating a route between two or more points and presenting the requested route as an overlay over a map of the surrounding environment. Therefore, it offers the subscriber several parameters for specifying the characteristics of the route (e.g., different route preferences like fastest, shortest or most scenic route). Additional to this overlay, the Route Service provides the user with route directions. The above mentioned possibility of giving route directions is available only in a rudimental form. A single direction consists of a string containing the instruction itself, the geometry of the route elements, where the described action takes place, encoded in GML, a bounding box bordering the next area of interest, the travel duration and the actual length of the current route segment. For more user specific route directions, subscribers can indicate the language in which they want the verbal instructions to be given. Optionally, the format of the direction can be set by a parameter. The default value is text/plain. Other options for setting this parameter are not specified in the OpenLS standard. The route directions, which can be encoded by this method, provide only verbal instructions. Multimodal directions including, for example, visualisation in form of pictograms describing the required action, can only be generated by the accessing application based on the geometry of the route. They are not further supported by additional information provided in the transferred data. Therefore, the given route directions are, as far as the verbal instruction is concerned, not flexible at all and cannot be adapted according to cognitive aspects by the client. 64

65 4.3. DATA STRUCTURE OF THE NAVIGATION SERVICE For the main part of the provided route directions, the verbal instructions are generated on the server and transferred an arbitrary string. Thus, it is not possible to decide by analysing the standard itself whether the provided route directions regard the aspects of cognitive ergonomic route directions discussed in chapter 2. Furthermore, encoding instructions in simple strings might be sufficient for providing route directions regarding some cognitive ergonomic aspects. However, it is not possible to specify these aspects in this context and force or at least imply their integration in route directions. Therefore, this form of giving route directions will not be further examined in this thesis Route directions in the Navigation Service The Navigation Service offers two possibilities of encoding route directions. Since it provides all parameters and all functions which are available in the Route Service, the first possibility are the verbal route directions described in the previous section. The second possibility is the enhancement of the Navigation Service in comparison to the Route Service, which describes each route instruction by a complex object. The provided objects contain preprocessed information which are necessary for generating route directions. That means that they do not contain already generated instructions which the client simply presents to the user without further processing. The application accessing this service has to create its own route directions based on the provided data. The advantage of transferring objects for each route direction rather than complete instructions is that the client application has the possibility to generate route directions that regard the users individual preferences. The parameters and information provided by the Navigation Service in an XLS element representing route directions are described in detail in the next section. There, the abstract data types and information provided by elements of these types are also explained. Whether the data structure and the provided data is applicable for generating cognitive ergonomic route directions is discussed in section Data structure of the Navigation Service The OpenLS specification defines the communication between a server providing LBS and a client. The interaction between client and server is specified as request and response pairs. In this section the data structure used in a Navigation Response is discussed and the single parameters of a navigation response and their usage are explained. The focus is on the elements used for encoding required to generate on the client route directions. 65

66 CHAPTER 4. OPENLS NavigationResponse For each service exists a R/R pair specified as a XML-schema. In the following, the possible elements of a NavigationResponse are explained. The data types are examined and the focus is placed on the response for a requested list of travel maneuvers. NavigateResponseType The document transferred by a server as answer to a requested navigation service consists of a XLS-document containing the type NavigationRequestType. For each requested feature of the Navigation Service, it contains an element which provides the appropriate information. A NavigateResponseType comprises specific elements containing the requested information and elements that are common for all types of responses (e.g., for error handling). All elements providing the actual information are optional. This, for example, allows for transferring only error codes in the case that an error occurred. The elements which are specific for a Navigation Response are: RouteHandle This optional element contains a reference to the requested route on the server. It allows the client to request additional information about the route or an alternate route. RouteSummary In a RouteSummary the route s overall characteristics are specified. The contained information consists of the estimated travel time, the whole distance the traveller has to cover for following the route and a bounding box bordering the area in which the route is located. The use of this element is optional. RouteGeometry The geometry of the route is provided by this optional element. It contains the coordinates of the relevant parts of the roads belonging to the route encoded in GML. RouteInstructionsList The RouteInstructionsList provides a list of turn-by-turn route instructions. It encodes the instructions according to the route directions used in the Route Service. (cf. section 4.4.1) The use of this element is optional. RouteMap Each of these optional elements contain a map of an requested area. The map is transferred as a binary picture encoded as base64 [17]. The number of provided maps is unbound. RouteManeuverList In the RouteManeuverList the route directions according to the more complex method used in the Navigation Service are contained (cf. section 4.4.2). The structure of the list and its elements is described in the next section. The use of this element is optional. 66

67 4.3. DATA STRUCTURE OF THE NAVIGATION SERVICE Structure of the route directions The more complex route directions offered by the Navigation Service are provided in the element RouteManeuverList of the complex type RouteManeuverListType, which is derived from the abstract type AbstractRouteManeuverListType. Their structure (cf. also Fig. 4.2) is described in the following: AbstractRouteManeuverListType This abstract type is the parent type of RouteManeuverListType, which is used for transferring route directions. It represents a simple list of so called travel maneuvers. A travel maneuver comprises the description of a decision point including the required action and the following route segment. Therefore, such a list consists a sequence of an unbounded number Manuever elements, where every element stands for a single maneuver. The Manuever elements in the list are of the type AbstractManeuverType, that specifies a single travel maneuver (cf. section 4.5.2). <<Abstract>> AbstractRouteManeuverList _Manuever <<simpletype>> positiveinteger <<simpletype>> RoadClassType 0..1 RouteManeuverListType maximumroadclass +id: ID required 1..* <<Abstract>> AbstractManeuverType +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +ManeuverPoint: gml:pointtype +_NextSegment: RouteSegmentExtendedType minoccurs=0 +actiontype: RouteActionType required +directionofturn: TurnDirectionType optional +junctiontype: JunctionCategoryType optional Figure 4.2: Data structure of a list of route maneuvers in OpenLS. RouteManeuverList The NavigationResponse for a requested navigation service provides a Route- ManeuverList. For each decision point along the route exists one instruction 67

68 CHAPTER 4. OPENLS describing the action the traveller has to perform. A RouteManeuverList contains all these travel maneuvers stored in a list. A RouteManeuverList element is of the complex type RouteManeuverList- Type, which is an extension of AbstractRouteManeuverListType and provides therefore all parameters of its parent. The extension adds the optional attribute maximumroadclass (RoadClassType), which provides the number of levels in the hierarchy. This hierarchy ranks the roads according to their relative size or importance in the route Data type of a single instruction In this section, the data type representing a single route direction is described. Furthermore the simple and complex types of the used attributes and elements are explained too. AbstractManeuverType The complex type AbstractManeuverType (cf. Fig ) is used for storing information about a single route instruction describing the action which has to be performed at a decision point, and the decision itself. <<Enumeration>> JunctionCategoryType +Intersection +Roundabout +EnclosedTrafficArea +EntranceRamp +ExitRamp +BoardingRamp +None <<Abstract>> AbstractManeuverType gml:pointtype cf. GML-Specification ManeuverPoint <<Abstract>> AbstractMeasureType 0..1 junctiontype +id: ID required +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +value: decimal required +accuracy: decimal optional DistanceType directionofturn <<Abstract>> RouteSegmentType Distance actiontype +TravelTime: Duration +name: string optional BoundingBox uom 0..1 <<Enumeration>> TurnDirectionType _NextSegment 0..1 RouteSegmentExtendedType +Straight +KeepLeft +KeepRight +SlightLeft +Left +SharpLeft +SlightRight +Right +SharpRight +UTurn <<Enumeration>> RouteActionType +Turn +ProceedTo +Embark +Disembark +Stop +Advisory <<Enumeration>> DistanceUnitType +KM +M +DM +MI +YD +FT 0..1 gml:envelopetype cf. GML-Specification Figure 4.3: Data structure of an abstract route maneuver in OpenLS. 68

69 4.3. DATA STRUCTURE OF THE NAVIGATION SERVICE For this purpose an AbstractManeuverType contains the following elements and attributes: Elements: ManeuverPoint The actual coordinates of the location where the described action takes place is stored in this attribute which contains an element of the complex type PointType. This type is element of the GML specification [4]. The encoding of coordinates is not discussed in this work. NextSegment Information about the next segment of the route is contained in this optional element of the type AbstractRouteSegmentType (cf. section ). Attributes: id For identification purposes a route instruction in OpenLS contains an attribute, in which an identification number is stored. The OpenLS makes use of the simple type ID predefined by XML schema. Its value has to be unique within one document in order to identify it unambiguously. junctionname Encoded as a simple string, the name of the current intersection is provided by this optional attribute. junctiontype The type of the current intersection is given by this optional attribute. It is of the simple type JunctionCategoryType (cf. section ). numberexitstopass This optional attribute of the type NonNegativeInteger is only used in conjunction with two of the categories of intersections, which are roundabout and complex intersections, and gives the number of exits the traveller has to pass before leaving a roundabout or a complex intersection. However, only the category Roundabout can be found in the enumeration of the simple type JunctionCategoryType. A complex intersection is not further mentioned or described in the OpenLS specification. actiontype Each instruction describes an action stored in this attribute of the simple type RouteActionType (cf. section and Fig 4.4). directionofturn If actiontype takes the value Turn this attribute of the simple type TurnDirectionType is used to specify the turn direction. If actiontype has a different value directionofturn should not be used. (cf. section ) 69

70 CHAPTER 4. OPENLS Turn ProceedTo Embark Disembark Stop Advisory Figure 4.4: List of possible action described in a route direction of OpenLS. AbstractRouteSegment A route direction in OpenLS always includes data about the next route segment the traveller must follow after passing the current decision point. This data is provided by elements of the type AbstractRouteSegment. They contain elements, that specify the distance along the segment, the estimated travel time and a bounding box enclosing the segment. Optionally such an element can also provide the name of the described segment. RouteActionType For specifying the action the traveller has to perform at the described decision point, OpenLS introduces several categories of possible actions. Hence, every route direction provides an attribute of the simple type RouteActionType. It enumerates the possible action categories. The listed values an attribute of this type can take and their meaning according to the documentation of OpenLS are: Turn: Instructing the traveller to enter the next route segment ProceedTo: Directing the traveller to enter a segment without specifying the action (e.g., used for the first route direction) Embark: Instructing the traveller enter, for example public transport Disembark: Directing the traveller to get off, for example public transport Stop: Notifying the travellers that they arrived at a stopping point Advisory: Used for instructing the travellers to follow the current route segment A special case in this enumeration is the action Turn. Only if the attribute of the type RouteActionType takes this value, the attribute TurnDirectionType, which 70

71 4.3. DATA STRUCTURE OF THE NAVIGATION SERVICE is described later in this chapter can be used. For all other values specifying a turn direction is not allowed. However, this constraint is only set by the documentation. A valid XLS document still can combine a turn direction with an attribute of the type RouteActionType that has taken another value than Turn. JunctionCategoryType Each route direction in OpenLS is categorised according to the type of intersection, where the described action has to be performed. Therefore, eight categories of intersections are introduced (cf. Fig. 4.5). Each route maneuver contains an attribute of the simple type JunctionCategoryType, which enumerates the possible types of intersections. Intersection Roundabout EnclosedTrafficArea EntranceRamp ExitRamp ChangeOver BoardingRamp None Figure 4.5: Categories of intersections in OpenLS. In this categorisation it is distinguished between general intersections, roundabouts, and enclosed traffic areas, which are described in the specification as an area in which unstructured traffic movements are allowed [2, page 22], entrance ramps to highways/motorways, the according exit ramps, change overs between highways/motorways, boarding ramps on public transport (e.g., a ferry) and, if the route direction does not describe an action at an intersection (e.g., if there is just a road name change or the instruction contains only an travel advisory) the attribute can take the value none. TurnDirectionType If the route instruction describes a turn the traveller has to perform the attribute directionofturn of the type TurnDirectionType is used, which specifies the directional change at the decision point (cf. Fig. 4.6). It should not be used if the attribute actiontype takes another value than Turn (cf. section ). The simple type TurnDirectionType defines an enumeration of all possible directional changes, which can be described in OpenLS. The directions are encoded as verbal expressions. Hence, it covers the eight sectors as described in chapter 2 (straight, left, right, slight left, slight right, sharp left, sharp right, u-turn) and additionally the directions keep left and keep right. OpenLS does not specify the 71

72 CHAPTER 4. OPENLS Straight KeepLeft KeepRight SlightLeft Left SharpLeft SlightRight Right SharpRight UTurn Figure 4.6: Possible directional changes in OpenLS. actual angular change of each direction. Therefore, it is not possible to decide on which direction model the specification is based ManeuverType: Extending the AbstractManeuverType Since the complex type AbstractManeuverType used in the AbstractRouteManeuverListType to describe a single route instruction is declared as abstract, elements which are directly of this type, cannot be created. Therefore, another complex type has to be defined inheriting the characteristics of an AbstractManeuverType. The OpenLS specification offers one non abstract complex type, which is derived from AbstractManeuverType (cf. Fig ). The ManeuverType inherits not only the attributes of the AbstractManeuverType, but also extends its functionality by adding new attributes and elements. The additional parameters are described in the following sections. AdvisoryType One of the main extensions added in the complex type ManeuverType is the introduction of the element Advisory of the complex type AdvisoryType. It allows the server to provide a much more elaborate advisory in an instruction. Every advisory is categorised by its attribute of the simple type AdvisoryCategoryType. The actual category depends on what the advisory is the traveller informing about. The possible categories are: StartLocation: The start point of the route EndLocation: The end point of the route ViaLocation: A special location the route leads through EnterPlace: Tells the travellers, that they are entering a named place (e.g., a country, state, or city) 72

73 <<Abstract>> AbstractManeuverType 73 Figure 4.7: Data structure of an extended route maneuver in OpenLS. <<Abstract>> AbstractMeasureType +value: decimal +accuracy: decimal uom KM +M +DM +MI +YD +FT DistanceType <<Enumeration>> DistanceUnitType AngleType +uom: string = DecimalDegrees optional 0..1 <<simpletype>> positiveinteger <<simpletype>> RoadClassType Length InterLinkAngle PositionOnRoundabout RoadClass ExitRampType ChangeoverType <<Abstract>> 0..1 AbstractManeuverGeometryType +id: ID optional <<Abstract>> AbstractLinkType LinkType +accessible: boolean optional +oneway: boolean optional +ismaneuverentrylink: boolean optional +ismaneuverexitlink: boolean optional +isroutelink: boolean optional +previouslinkid: IDREF optional ConnectedLinksType +id: ID required +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +ManeuverPoint: gml:pointtype +_NextSegment: RouteSegmentExtendedType minoccurs=0 +actiontype: RouteActionType required +directionofturn: TurnDirectionType optional +junctiontype: JunctionCategoryType optional ManeuverType +towardssigntext: string optional +nextmaneuverfollowsimmediately: boolean optional Geometry 1..* EntranceRampType BoardingRampType Place 0..1 NamedPlaceType +name: string _Link AdvisoryType Advisory associatedname: string optional type <<Enumeration>> 0..1 NamedPlaceClassification +CountrySubdivision +CountrySecondarySubdivision +Municipality IntersectionType RoundaboutType EnclosedTrafficAreaType +MunicipalitySubdivision placetype <<Enumeration>> AdvisoryCategoryType +StartLocation +EndLocation +ViaLocation +EnterPlace +ExitPlace +BypassCity +StreetNameChange +Tollbooth +Landmark +Crossroad +HighwaysMerge +RampMerge +RoadsMerge type sideofroad +Left <<Enumeration>> SideOfRoadType +Right +Both 4.3. DATA STRUCTURE OF THE NAVIGATION SERVICE

74 CHAPTER 4. OPENLS ExitPlace: Leaving a named place BypassCity: Turning on a branch to bypass a city StreetNameChange: Change of the street name Tollbooth: Passing a tollbooth Landmark: Passing or turning at a landmark Crossroad: Passing or turning at a crossroad HighwaysMerge: Current highway the traveller is proceeding on is merging with another highway RampMerge: A ramp merges with a current road RoadsMerge: The current road the traveller is proceeding on is merging with another road Furthermore, an advisory is associated with a name (associatedname) and contains an optional attribute of the type NamedPlaceClassification. This provides the level in a hierarchy defined by comprising the different types: CountrySub- Division, CountrySecondarySubdivision, Municipality, and MunicipalitySubdivision. A further explanation of this hierarchy is not given. Additionally, an advisory includes optionally the attribute sideofroad of the type sideofroad, which associates the advisory with one side of the road or both. namedplacetype Similar to an advisory, the extended route instructions have an attribute of the type NamedPlaceClassification. This contains the level in the above mentioned hierarchy (CountrySubDivision, CountrySecondarySubdivision, Municipality, and MunicipalitySubdivision). Geometry The extended version of the route directions also provides a more elaborate description of the geometry of the current maneuver. This information is given in the attribute Geometry of the type AbstractManeuverGeometryType. Derived from AbstractManeuverGeometryType and AbstractLinkType, the complex type LinkType consists of several attributes and elements. The general geometry of the link is described by the element InterLinkAngle of the type AngleType. It gives the angle of the outgoing branch relative to the branch on which the traveller arrives. If the current direction describes an action at a roundabout, the position of the link on the roundabout is given (PositionOnRoundabout of the type AngleType) and the actual length of the (next) link is provided (Length). 74

75 4.4. COGNITIVE ERGONOMIC ROUTE DIRECTIONS IN OPENLS Apart from the actual geometric information, the type of the road are provided. It contains the attribute roadclass of the type RoadClassType, providing the class of the road described by a simple positive integer, a boolean attribute providing the accessibility of the road (Accessible and a boolean attribute storing, whether the road is a one way street or not (oneway). All these attributes are optional. The next group of information given in this type regards the role of the link in the actual route. A link can be an entrance link (boolean attribute ismaneuver- EntranceLink), an exit link (boolean attribute ismaneuverexitlink) and a route link (boolean attribute isroutelink). The exact meaning of these links is not specified [4, page 38]. Again, the use of these attributes is optional. Finally, it contains some internal information about the structure. Every link has an optional ID (attribute id of the type ID) and it also provides optionally the ID of the previous link (attribute previouslinkid of the type ID). towardssigntext A ManeuverType can contain an optional attribute of the type towardssigntext. This type provides a simple string in which the name of the place (usually a city) the route is branched towards is given. nextmaneuverfollowsimmediately The meaning of this boolean attribute is not specified in the OpenLS specification. It indicates probably, whether the next action described in the next route instruction follows immediately after the current action (the travellers have only to cover a short distance until they reach the next decision point). Its usage is optional. 4.4 Cognitive ergonomic route directions in OpenLS Since the OpenLS specification offers the possibility of giving route directions, the questions arises how far those instructions accord to aspects of cognitive ergonomic route directions discussed in chapter 2. Is it possible to encode all necessary information in order to generate cognitive ergonomic route directions on the basis of AbstractManeuverType or ManeuverType? Making direction concepts more precise In section 2.1, the importance of using precise direction concepts in route instruction in order to help the traveller to navigate at the decision points along a route was outlined. The following section will now examine how far this is possible in OpenLS. 75

76 CHAPTER 4. OPENLS Direction model A first step in generating precise route directions is to use a direction model that accords to directions identified by human conceptualisation. In OpenLS the necessary directional change is encoded in an attribute of the simple type TurnDirectionType provided by the complex type AbstractManeuverType (cf. section 4.5.3). This simple type defines an enumeration of verbal description of the possible directions. The list contains ten different elements. Eight of these elements accord to the eight sectors of the direction models discussed in section The two remaining directions (KeepLeft and KeepRight) describe more of an action including directional information rather than a plain directional change. The documentation of the OpenLS specification does not further explain the usage of the elements of this enumeration. Hence, it is not clear how the underlying direction model looks like. For example, a model with homogeneous sectors can be applied as well as the model proposed by Klippel et al. [20]. The documentation does not mention to which angle each verbal description accords. Therefore, the server can decide arbitrarily how to interpret these labels as well as the client. If both do not interpret them the same way, the generated route direction can easily become confusing for the user. Naming the structure Section outlined how the structure of the current intersection supports the navigation process of travellers. It helps to identify the intersection, gives a rough impression of what must be expected at the intersection and therefore, prepares the travellers to perform the correct action. For specifying the current intersection where the described action takes place, the OpenLS specification offers an attribute of the simple type JunctionCategoryType (cf. section 4.5.3). It defines an enumeration of different categories of intersections. Indeed, the enumeration contains elements that are also proposed in section for the usage in route directions (e.g., Roundabout), but by far not all that are necessary. Most of the listed categories (e.g., BoardingRamp or Changeover) describe rather the function of the intersection within the street network rather than the spatial situation. However, even though the information about the function is definitely helpful for the traveller, not describing even roughly the spatial situation the user has to expect is not sufficient. Most prominently the category intersection is insufficient for these purposes. It does not provide any information about how the current intersection is structured. For example based on this information, the traveller cannot figure out how many branches there are and what exactly the described turn by the attribute TurnDirectionType means in the context of the current intersection. 76

77 4.4. COGNITIVE ERGONOMIC ROUTE DIRECTIONS IN OPENLS Using landmarks As outlined in section 2.2, landmarks play an important role in the navigation process of humans and are therefore heavily used in human generated route directions. Despite the lack of usage in route instruction provided commercial navigation services, it would be desirable to integrate their use in a standard such as OpenLS. A standard route direction in OpenLS (AbstractManeuverType) does not offer the usage of landmarks in an instruction at all. There exists no attribute that could be used for storing the information about a landmark. On the other hand, a ManeuverType, the OpenLS extension of the complex type AbstractManeuverType, explicitly provides in the attribute AdvisoryType the possibility to describe a landmark. The AdvisoryType can be explicitly labeled as a description of a landmark (the attribute of the type AdvisoryCategory- Type can be set on the value Landmark), but then does not offer even rudimental functionality to describe the landmark itself. The only possibility is to provide the name of the landmark in the attribute assocname. Since this is encoded as a simple string, it could be of course used for a longer verbal description. Therefore, the current version of the OpenLS Navigation Service is not able to offer the necessary functionality for integrating landmarks into route directions. The attributes for this purpose provided and elements are completely insufficient, even to describe a landmark in its simplest form. Encoding information about a landmark in an extent necessary for the use of landmarks described in section 2.2 is impossible Subsuming route directions The current OpenLS specification offers no possibility to combine elementary route direction elements to higher order chunks. In a RouteManeuverList each single decision point is listed as a single instruction. Combining several decision points in one element of the list is not possible. The route directions are not related to each other except from being part of the same list. An element of this list does not contain elements of the same type, so arranging the route directions in a hierarchy is also not intended. Of course, it is possible to create higher order route elements based on the available attributes and elements of a maneuver. In this case rather unimportant directions, for example, instructions which require no directional change, could be omitted. However, it is not possible to indicate these directions as higher order route segments and most of the attributes which are necessary to describe such a chunk properly are missing. So if the current data structure is used for chunked route directions, it is not apparent for the users that such an instruction combines several decision points to a single direction. Providing them with the missing information, if necessary, is not possible since OpenLS does not offer requesting 77

78 CHAPTER 4. OPENLS a complete/incomplete instructions list. So the user has not the possibility to zoom in, if the given directions are not detailed sufficiently. These missing possibilities to generate chunked route directions arranged in a hierarchy make it necessary to extend the current version of the Navigation Service by appropriate attributes and elements in order to allow the usage of higher order route elements according to proposals discussed in the previous chapters (cf. section 2.3). 4.5 Why has OpenLS been chosen as basis? The main concern of this work is the usage of cognitive ergonomic aspects in automatically generated route directions. In order to achieve this goal, the aspects discussed in chapter 2 have to be integrated in a system for generating route directions. For this, the OpenLS specification was chosen. The advantages and therefore the reasons for this choice, and the disadvantages and problems the usage of OpenLS entails are discussed in the following two sections Advantages OpenLS provides as a basis for the integration of the discussed aspects of cognitive ergonomic route directions several advantages. The Open GIS Consortium is an open collaboration of companies and also other partners such as universities. The main focus lies on the development of standards for commercial use. Within this scope the OpenLS specification was developed to meet the demands of commercial location based services. Since it is an open standard, which is actually implemented and used, it offers a platform for location based services defining everything necessary for a client/server application providing route directions. Embedding the aspects of cognitive ergonomic route directions in a specification, allows for implementing it without additional work as a functioning system. Integrated in several other standards, the main part of the OpenLS specification consists of defining the communication between client and server. The exchanged documents are all based on XLS. As a XML-schema, XLS can be easily extended and new features can be integrated. Moreover, the modular structure of XLS allows to extend and restructure parts without affecting other modules. Therefore, only a few types had to be adapted to the requirements of cognitive ergonomic route directions. With the definition of the Navigation Service, the OpenLS specification provides a data model which is the basis for the generation of route instructions. This offers the possibility for designing data types that support cognitive ergonomic route directions. These are embedded in an existing structure and therefore, integrated in an existing system. 78

79 4.5. WHY HAS OPENLS BEEN CHOSEN AS BASIS? Since the focus of this work is on encoding the required data and not on the actual generation of route direction, for example, in a verbal or pictorial form, the Navigation Service offers optimal conditions for this approach. The later proposed data structure is meant to store exactly the information that is necessary to generate route direction with respect to the aspects of cognitive ergonomic route directions discussed in chapter 2. The OpenLS Navigation Service should transfer exactly the information required in the generation process and therefore, it is an ideal framework for this thesis Disadvantages Despite the advantages of the OpenLS specification, there are also some problems and difficulties involved. The Navigation Service plays a special role in the OpenLS specification. Since it is not part of the core services and since the current developments focus on these services, its improvement has been neglected. Therefore, it has not been implemented yet. How its status will change in the future is hard to predict. As long as the proposed changes in the OpenLS specification are not included in the standard, a server implementing them is, as far as the Navigation Service is concerned, incompatible to non abstract part of the Navigation Service. Of course, a parallel implementation is possible. However, this requires special adapted client software and this leads to the loss of the advantages of an open standard. If it is not completely accessible for everyone, the provided services cannot be sold to all potential customers. Even though the disadvantages of this approach of formalising route directions based on the OpenLS specification complicates this undertaking, the advantages still prevail. Therefore, the OpenLS specification is an appropriate environment for this work. 79

80

81 5 Extending OpenLS As outlined in chapter 4, the OpenLS standard does not support cognitive ergonomic route directions. In this chapter, an extension is proposed that integrates precise direction concepts, landmarks and the subsuming route directions in the specification. Thus, the abstract data types of the OpenLS Navigation Service which provide data for the generation of route directions (AbstractRouteManeuverList, AbstractManeuverType and all related types) are restructured. The changes, their advantages and implementation are described in detail in the following chapter. The XML-code of the actual implementation of the extended XLS types can be found in Appendix A. 5.1 Used approach for the integration Since the current version of the OpenLS specification does not support all necessary features for generating cognitive ergonomic route direction, the standard or more precisely the underlying data model, has to be extended. For achieving this aim, it is sufficient only to adapt some types in the data structure of the navigation service. The extension will replace the complex types AbstractRouteManeuverList, AbstractManeuverType and all related types. The proposed data types are integrated in the data structure in the same way the official extension of the AbstractManeuverType, the ManeuverType are implemented. All new types are derived from the according original type. In the following two sections, the aspects regarded in the extension are outlined. Hence, it is distinguished between aspects of human ergonomic route directions and additional aspects which are integrated for more technical reasons. Furthermore, the approach for the technical realisation is briefly discussed Regarded aspects of cognitive ergonomic route directions The proposed extension of the OpenLS specification introduces several new aspects of giving route directions. The main part is derived from the aspects of cognitive ergonomic route directions discussed in chapter 2. Additionally, some other features are introduced, which shall just improve the usability of the pro- 81

82 CHAPTER 5. EXTENDING OPENLS vided data. The aspects regarded in the extension are listed in the following two sections: Cognitive ergonomic route directions The main concern of the proposed extension of the OpenLS specification is to enable the possibility of generating automatically cognitive ergonomic route directions based on the OpenLS data model. Thus, all aspects discussed in chapter 2 are regarded: Direction model: The direction model, on which the encoding of the provided turn direction is based, is adapted according to Klippel s approach [20] in combination with naming the structure of the intersection, both discussed in section 2.1. The final implementation is described in section Structure of intersections: As discussed in section mentioning the spatial configuration helps the traveller to orientate. How this is regarded in the OpenLS extension can be found in section Landmarks: Landmarks play an important role in giving route direction (cf. section 2.2). Therefore, a more elaborated model for their description is introduced in the OpenLS specification (cf. section 5.6). Chunking: The extended version of OpenLS offers now the possibility of chunking (cf. section 2.3). The implementation of the combination of Klippel s [24] and Dale s [5] approach is described in section 5.7 Additionally introduced features Besides of the aspects of cognitive ergonomic route directions some additional smaller features are integrated in the OpenLS specification. The intention by introducing them was to make the usage of the data structure easier, clearer and less error prone. Start point: The start of a route is a crucial point in a description of a route. Accordingly, it is treated separately in the extended version of the OpenLS specification (cf. section 5.3.1). End point: Similar to the start, point the end point of route requires special attributes. Hence, a special complex type providing the necessary attributes is introduced (cf. section 5.3.2). 82

83 5.2. EXTENDING ROUTEMANEUVERLIST Technical realisation The data about a single instruction in a Navigation Response is significantly increased in the new version of the OpenLS specification. Especially the complex type ManeuverType has been radically restructured and extended. Therefore, the compatibility to the original version of the AbstractManeuverType is not given. A server or client that supports only one of version cannot deal with the abstract data types of the other. 5.2 Extending RouteManeuverList In a list of single route directions, the start point and the end point of the route play a special role. The start point instruction helps the traveller to orientate and to commence the route in the correct direction. The end point unambiguously identifies the actual destination. Since start and end point have to be treated separately, they should also be specially indicated in the list of the route maneuver. Thus, a complex type XRouteManeuverListType is derived from AbstractRouteManeuverList, which adds two elements containing the information about the start and the end point of route. The already existing elements of a AbstractRouteManeuverList, the unbounded number of elements of the type AbstractManeuverType, remain and thus, assure the compatibility of the next extensions to the original abstract version of the OpenLS Navigation Service. Additionally, like in RouteManeuverList the attribute maximumroadclass is introduced. An UML diagram of the relationship between the single types, their attributes and elements is shown in figure 5.1. The exact structure of a start and an end point is outlined in the following two sections XStartingManeuverType Orientating the traveller at the beginning of the route is a crucial part in giving route directions. It has to be assured that the traveller follows the first route segment, starting at the by her provided address, in the right directions. Therefore, the complex type XStartingManeuver is introduced providing a set of attributes and elements containing the necessary and available information for the first orientation (cf. Fig ). Position This element gives the exact geographic position of the start point of the route encoded as an gml:pointtype. Address The element Address provides the address of the start point of the route. For encoding this information, the OpenLS specification defined complex type AddressType is used. It can contain either an unstructured free form 83

84 CHAPTER 5. EXTENDING OPENLS <<Abstract>> AbstractRouteManeuverList _Manuever 1..* <<Abstract>> AbstractManeuverType cf. figure xy <<simpletype>> positiveinteger XRouteManeuverListType <<simpletype>> RoadClassType 0..1 maximumroadclass EndManeuver XEndManeuverType +Address: AddressType +SideOfRoad: SidOfRoadType optional +position: gml:pointtype +Landmark: EndLMType optional StartingManeuver XStartingManeuverType +Address: AddressType +SideOfRoad: SidOfRoadType optional +position: gml:pointtype +RoadDiretion: RoadDirectionType optional +Landmark: StratLMType optional +Orientation: gml:compasspointenumeration optional Figure 5.1: Diagram of the extended data structure of a route maneuver list. address (a simple string), a street address or an intersection address and some additional elements (e.g., a post code). RoadDirection Starting at the address/position, the travellers has to follow the first segment of the route. At the start point, facing the road so that their line of sight and a tangent to the travellers where the closest point on the road intersect orthogonal the traveller can either turn left or right or they can proceed (in some special cases) straight. Therefore, the attribute RoadDirection can be one element of the enumeration of the simple type RoadDirection: left, right or straight. Orientation Additionally, to the orientation respectively to road and start point the complex type XStartingManeuver offers an attribute providing the direction in which the traveller has to go according to the cardinal direction. For this purpose the simple type from the GML specification Compass- PointEnumeration is used. It splits the possible directions into 16 homogeneous sectors. Each sector is represented by a cardinal direction (e.g., south). Landmark The third possibility of orientating the traveller at the origin of the route is to describe the direction relatively to a landmark. The landmark for this purpose is provided by the element Landmark. This element is of the complex type StartPointLMLMType. A detailed description of this type can be found in section

85 5.2. EXTENDING ROUTEMANEUVERLIST Traveller First route segment Line of sight Start location Figure 5.2: This figure depicts the assumed position of the traveller at the start of a route. To follow the route the traveller had to turn right. id As a usual route maneuver a start maneuver has an ID, that identifies it unambiguously XEndManeuverType Like the start point of a route, the end point is encoded separately. Its main function is to provide all information in order to enable the traveller to identify the destination of her route. Therefore, elements of the type provide the following attributes and elements, which offer the necessary information (cf. Fig ). Position The exact geographic position encoded as an gml:pointtype of the start point of the route is provided by the element Position. Address This element contains the address of the end point of the route. For encoding this information, the XLS complex type AddressType is used (cf. section 5.3.1). SideOfRoad The end point of the route can be located either on the left side, the right side or on both sides of the road to the current direction the user is travelling in. The simple type SideOfRoad offers the three values: left, right and both. The attribute SideOfRoad of a EndManeuverType can take one of them as value. Landmark For describing the position of the end of the route, a landmark can also be used. The spatial relation between the end point and the landmark has to be described, as well as the landmark itself. The necessary features for this purpose are provided by the complex type EndPointLMType. An element of the type EndManeuverType contains the element Landmark, which is of this type. 85

86 86 Figure 5.3: Data structure of a start maneuver and an end maneuver. <<Enumeration>> RoadDirectionType +Left +Right +Straight StartLMType +PictureData: string (base64) choice +PictureURL: string choice +SpatialRelation: StartLMRelation optional +SideOfRoad: SideOfRoadType +PointPosition: gml:pointtype Choice +LinePosition: gml:linetype Choice +AreaPosition: gml:polygontype Choice XStartingManeuver +id: ID required Landmark Orientation SideOfRoad <<Enumeration>> SideOfRoadType +Left +Right +Both gml:pointtype cf. GML-specification gml:compasspointenumeration cf. GML-specification XEndManeuver 0..1 RoadDirection Address AddressType Address Landmark cf. OpenLS-Specification Position +id: ID required <<Abstract>> AbstractManeuverType +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +ManeuverPoint: gml:pointtype +_NextSegment: RouteSegmentExtendedType minoccurs=0 +actiontype: RouteActionType required +directionofturn: TurnDirectionType optional +junctiontype: JunctionCategoryType optional SideOfRoad Position EndLMType +PictureData: string (base64) choice +PictureURL: string choice +SpatialRelation: EndLMRelation optional +SideOfRoad: SideOfRoadType +PointPosition: gml:pointtype Choice +LinePosition: gml:linetype Choice +AreaPosition: gml:polygontype Choice +id: ID required PreviousSegment XRouteSegmentExtendedType CHAPTER 5. EXTENDING OPENLS +Landmark: NonDPPLMType

87 5.3. INTRODUCING XMANEUVERTYPE previoussegment In the data structure, a decision point of a route and the route segment leading to this decision point are stored together. Hence, the last route segment leading to the end point of the route has to be stored together with the end point. The element previoussegment of the complex type XRouteSegmentExtendedType contains this segment. This complex type is described in section id As a usual route maneuver, a start maneuver has an ID that identifies it unambiguously. 5.3 Introducing XManeuverType As discussed in section 4.6, route directions based on the complex type AbstractManeuverType do not support cognitive ergonomic route directions. Also the from AbstractManeuverType derived type ManeuverType does not offer the necessary features to encode all necessary information for generating the aspects of cognitive ergonomic route instructions described in chapter 2. Hence, the here proposed extension of the OpenLS Navigation Service introduces a new complex type XManeuverType for encoding single route directions, which provides the required elements and attributes (cf. Fig ) Deriving from AbstractManeuverType Like the original ManeuverType XManeuverType is derived from AbstractManeuverType. Even though it replaces all of the elements and attributes of the super type except of one, the derivation is necessary to assure the compatibility to the original, abstract version of the Navigation Service. The reused attributes is: id This attribute encodes an identification number in order to identify the direction unambiguously as an attribute of the simple type ID New introduced elements and attributes previoussegment In the extension proposed a decision point and the route segment which leads to it, form a unit (e.g., Follow street XY and then turn left at the church. ). This schema is commonly used in human generated route directions and current navigation services. Therefore, the element previoussegment of the complex type XRouteSegmentExtendedType is introduced. This type is described in the following section. 87

88 CHAPTER 5. EXTENDING OPENLS <<Abstract>> AbstractManeuverType +id: ID required +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +ManeuverPoint: gml:pointtype +_NextSegment: RouteSegmentExtendedType minoccurs=0 +actiontype: RouteActionType required +directionofturn: TurnDirectionType optional +junctiontype: JunctionCategoryType optional RouteSegmentExtendedType XManeuverType previoussegment XRouteSegmentExtendedType Landmark <<Abstract>> AbstractJunctionType +RouteBranch: gml:angletype +NoRouteBranch: gml:angletype maxoccur = unbounded JunctionCategory Landmark 0..* <<Abstract>> NonDPPLMType +SpatialRelation: SpatialRelationNonDPType +PointPosition: gml:pointtype Choice +LinePosition: gml:linestringtype Choice +AreaPosition: gml:polygontype Choice 0..* Figure 5.4: The extended data structure of a route maneuver. nextstreet This attribute contains the name of the street the travellers are turning in when they perform the described maneuver. The provided information is also provided by other elements (e.g., the next segment, which is still contained because of the derivation, or the following maneuver), but accessing it via them would be inconvenient or lead to deprecated operations. JunctionCategory Since the element JunctionType of the complex type AbstractManeuverType does not offer the features required for making route directions more precise, the element JunctionCategory is introduced. It is of the complex type AbstractJunctionType, which is discussed in section 5.5. As outlined in section 2.2 landmarks play an important role in the understanding of route directions by humans. Hence, elements providing information about landmarks are introduced. Decision points can be related to 1-Element landmarks. n Elements landmarks can only be associated with chunks (cf. section 5.7). Since a decision point can have more than one landmark, the amount of elements representing a landmark is unbounded. Landmark This element of the abstract complex Abstract1ElementLMType provides all required information about a landmark with a point-like function. 88

89 5.3. INTRODUCING XMANEUVERTYPE A decision point is not necessarily related to a landmark of this type. However, the number of landmarks is unbounded. The attributes and elements of AbstractPointLikeLMType and its sub types are described in section Replacing NextSegment by CurrentSegment The proposed extension of the OpenLS Navigation Service combines in an elementary route direction always (apart from the start point) a decision point and the previous route segment. The route directions generated on this basis generally follow the schema: Follow street XY and turn right after the landmark. This schema is also quite commonly used by humans giving route instructions, as well as in instructions generated by navigation services. In principle, route directions created on the basis of the data structure may follow a different schema. In an element based on the complex type AbstractManeuverType of the original version of the Navigation Service, a decision point is combined in an instruction with the following route segment, rather than with the previous segment. However, it is possible to restructure the instructions and combine a decision point with the following decision point. Since it has to be possible to relate a route segment to a 1 Element landmark, a new type providing the necessary element for storing the information about a landmark is introduced. The complex type XRouteSegmentExtendedType is derived from the original XLS complex type RouteSegmentExtendedType and therefore, contains the same attributes and elements (cf. section 4.5.3). In order to enable the use of landmarks, new elements are introduced: Landmark The information about a landmark with a point like function is stored in this element of the type NonDPPLMType; this structure is also discussed in section 5.6. A segment can be related with an unbounded number of landmarks of this type. RoadNameChange This attribute of the type RoadNameChangeType is also introduced in this extension and provides the necessary information if the street name changes at a segment and not at a decision point. The complex type RoadNameChangeType contains therefore, the new street name encoded as string and the position of the change as gml:pointtype. Streetname This attribute stores the name of the road, to which the segment belongs. In contrast to the name provided by RouteSegmentExtendedType, this attribute is required. 89

90 CHAPTER 5. EXTENDING OPENLS 5.4 Making route directions more precise According to the aspects discussed in section 2.1 this OpenLS extension introduces data types, which describes the spatial situation at a decision point as exactly as necessary and combines this with a direction concept specifying the turn direction. The data is provided and how it is structured in the new introduced data types is outlined in the following sections Direction model In the current version of the Navigation Service, a direction is described by a verbal expression. OpenLS offers collection of ten verbal expressions in a simple data type. How the underlying direction model structuring space is specified is not further explained. Similar to the original verbal expressions, the proposed extension of the specification offers simple types for different kinds of intersections providing an appropriate direction concept and its respective direction. Relating structure of the intersection and appropriate directions constrains an unmeaningful combination. The directions for each type of intersection are encoded as enumerations of verbal expression. However, these verbal expressions are not in any case supposed to be used in the final generated route instruction. Verbal expressions are only used in order to make the encoding of the data readable for humans. The directions given in the instructions are all constrained by the type of the intersection. These types require only the directions straight, left and right. Hence, a direction model, as discussed in section is not represented in this extension. The definition of left and right is intelligible; the directions are divided by the straight axis. Directions in the left half are represented by left, the directions on the right side by right. However, it is not exactly specified which directions should be represented by straight and subject to ongoing research Naming the structure Describing the spatial situation at an intersection helps the travellers to orientate themself and allows to simplify the given turn directions. For example, specifying an intersection as T intersection reduces the possible directions to the two options left and right. There, the street on which the traveller is approaching the decision point ends in an orthogonally running road. An element representing an intersection provides the spatial situation by listing all branches. This allows for producing, for example, a pictorial representation of the intersection. Furthermore, all intersections are classified by standard types. The offered types of intersections are listed in figure

91 5.4. MAKING ROUTE DIRECTIONS MORE PRECISE T Intersection Fork intersection Standard intersection Intersection with competing branches Small roundabout Large roundabout Figure 5.5: List of possible types of intersections Types representing intersections The elements of the current OpenLS version do not provide all features required to generate precise route directions and its data structure does not constrain the generation in a way that minimises the possibility of creating unambiguous instructions. Therefore, several new types for supporting this purpose are introduced (cf. Fig ). AbstractJunctionType The proposed extension classifies each intersection into a category. Each category is represented by a complex type derived from the AbstractJunctionType. AbstractJunctionType provides the attribute elements which are necessary for all types of intersections. name If an intersection has a special name identifying it, the name can be stored in this optional attribute encoded as a simple string. Encoding the spatial structure For each intersection its spatial structure has to be provided. This allows to give the traveller an exact description of the spatial situation and helps her to orientate. Every branch of the intersection has to be listed. The branches are encoded as complex type Branch. Introduced in the proposed extension, this type provides for a branch the angle between branch and the route segment leading to the intersection as gml:angletype and the street name of the branch. RouteBranchOut The branch of the intersection on which the traveller must be stored in separate element, since it has to be possible to distinguish it from the other branches due to its special role. 91

92 CHAPTER 5. EXTENDING OPENLS NoRouteBranch All other branches are stored in an element with the name NoRouteBranch. The occurrence of this element is unbounded. gml:angletype cf. GML-Specification RouteBranch <<Abstract>> NoRouteBranche 0..* AbstractJunctionType gml:angletype cf. GML-Specification <<Abstract>> nocompetingbranchestype CompetingBranchesType +numberexitstopass: positiveinteger SmallRoundaboutType LargeRoundaboutType +numberexitstopass: positiveinteger TurnDirection TIntersectionType StandardIntersectionType TurnDirection <<Enumeration>> TurnDirectionTypeSR +Right +Left ForkIntersectionType TurnDirection <<Enumeration>> TurnDirectionTypeC +Straight TurnDirection TurnDirection +Right +Left <<Enumeration>> <<Enumeration>> TurnDirectionTypeSR +Right +Left TurnDirectionTypeSR +Right +Left +Straight Figure 5.6: Data structure of the different types of intersections. AbstractNoCompetingBranchesType Junctions of the type AbstractNoCompetingBranchesType can be classified in one of the categories T intersection, Fork intersection and standard intersection (cf. section 2.1.2). For creating a single route instruction for these classes of intersection it is sufficient to know the direction of the turn and the category of the intersection. From this abstract type all three sub categories are derived. TIntersectionType T intersection are all intersections where the road on which the traveller arrives, ends at the intersection. If the traveller approaches at the same intersection on a different branch, it is not classified as a T intersection but as a standard intersection (cf. section 2.1.2). The only attribute this type has contains the direction of the turn. It is of the simple type TFTurnDirectionType and can only take the value left or right. ForkIntersection Similar to the T intersection, the incoming branch of the intersection decides whether it is categorised as fork intersection or not. The traveller has to arrive on the branch that splits into the two other branches (cf. section 2.1.2). Also similar to the T intersection, it provides only one attribute of the simple type TFTurnDirectionType. 92

93 5.4. MAKING ROUTE DIRECTIONS MORE PRECISE StandardIntersectionType All other intersections that have no branch competing with the outgoing branch belong to the category standard intersection (cf. section 2.1.2). The complex type for this group has only one attribute containing the turn direction. In this case it is of the simple type SITurnDirectionType and can therefore take the value left, right or straight. CompetingBranchesType The set of possible turn directions is divided by the straight-axis in two parts, a left and a right half. Two branches of an intersection compete with each other, if they are both either in the right or the left half. Hence, a branch going straight cannot compete with another branch (cf. section 2.1). If at an intersection the outgoing branch competes with another branch, this intersection is represented by the complex type CompetingBranchesType. For this type of intersection, a direction concept is used that combines a rough turn direction (left or right) with an ordering concept; the number of the out going branch ordered in its half in respect with the straight axis. Therefore, an element of the type CompetingBranchesType has two attributes. The BranchNumber contains the number in the ordering concept encoded as a positive integer value. TurnDirection is of simple type TurnDirectinTypeC, which can take either the value left or right, whereas these values stand for one of the two halfs of the space of turn directions. SmallRoundAboutType Two different class exist for roundabouts. Small roundabouts are encoded as elements of the type SmallRoundaboutType. These roundabouts are so small that an instruction like Turn left is clear. Thus, the only attribute of this complex type representing an intersection is of the simple type TurnDirectionType. An attribute of this type can take a value according to the direction model discussed in section 2.1. LargeRoundaboutType The second class of roundabouts is for large roundabouts. For large roundabouts the use of turn directions is ambiguous. Hence, the instruction for performing a travel maneuver is to give the number of exits the traveller must pass in the roundabout. Therefore, the only attribute that an element the complex type LargeRoundaboutType has is a simple integer value, which gives the number of exits to pass at the roundabout. 93

94 CHAPTER 5. EXTENDING OPENLS 5.5 Integration of landmarks in OpenLS Landmarks play an important role in describing a route to a cognitive agent (cf. section 2.2). They can have different purposes and functions, for example, they can be used for identifying segments and decision points, they can help the traveller to orientate or they can specify a required action. According to their different functions, Klippel et al. designed a taxonomy for the classification of landmarks (cf. [23] and section 2.2.3). This taxonomy is used as a basis for the abstract data types representing landmarks in the proposed extension of the OpenLS specification. The usage and function of these new introduced types depends on the context of other types, which are contained as elements. Therefore, this is discussed in the description of the complex types, which landmarks contain as an element. In the following section, the types providing the information about a landmark itself are discussed AbstractLandmarkType All complex types representing a particular type of landmark are derived from the abstract type AbstractLandmarkType. This type contains all elements and attributes, which have to be part of each other complex type representing a landmark. The elements and attributes, which are common for all types of landmarks and therefore are the only elements/attributes of AbstractLandmarkType are the name (Name) and a description (description) of the landmark. The attribute Name should contain the official name of the landmark. The description should provide all information that is necessary to enable the traveller to identify the landmark in the environment. The use of the attribute Name is optional and its content is encoded as a simple string. The element description is of the complex type AbstractLMDescription. More information about this type is given in section Landmarks for orientation at Start and End Point As outlined in section and 2.2.5, the start point and the end point of a route are crucial in giving route directions. The traveller has to be enabled to orientate herself in her environment in order to identify and follow the first route segment at the beginning of the route and to identify her goal at the end. Embedded in the extension of the complex type AbstractRouteManeuverList- Type by XRouteManeuverListType the two elements StartingMAneuverType and EndMAneuverType of StartingPointLMType and EndPointLMType are introduced. They provide all information about the landmarks used for orientating 94

95 5.5. INTEGRATION OF LANDMARKS IN OPENLS the traveller. The necessary elements and attributes of the two types are described in following. StartingPointLMType By choosing the information that is provided by an element representing a start point the special situation of the traveller has to be regarded. It is to assume that the travellers are not familiar with their environment. Therefore, they do not know which direction they have to head in order to follow the route. They also do not know where the landmark is located and how it looks like. Thus, the complex type StartingPointLMType is introduced (cf. Fig ). Additionally to the attribute Name and the element Description, which are already contained by the abstract complex type AbstractLandmarkType, the following elements are provided: PointPosition, LinePosition, AreaPosition For the exact geographic position of the landmark, it can be chosen between these three elements. Which one is selected depends on the geometry of the landmark. The position is encoded as gml:pointtype, gml:linestringtype or gml:polygontype. Orientation Since this type of landmark is used to help the traveller to orientate in general without relation to any other elements of the route directions (for example, roads or current travel direction), providing the general orientation of the landmark with respect to the traveller s current position is in some cases helpful. Thus, the attribute Orientation contains this information encoded as an element of the simple type gml:compasspointenumeration, which splits the space of possible orientations into 16 homogeneous sectors labeled with expressions, for example S for south or NW for northwest. SpatialRelation In this optional attribute, the information is provided if the traveller has to follow the first segment towards or away from the landmark. EndPointLMType In contrast to the start of a route, the traveller is on the last route segment already oriented. The task of the last instruction is to support the traveller to identify her final goal. The end point of a route is in most cases a street address, which is usually identified by its house number. Since this number is quite often not visible or easy to spot for the traveller, it is helpful to describe the position of the goal of the route in relation to a much more salient landmark. Therefore, the complex type EndPointLMType is introduced (cf. Fig 5.5.2). It provides, additionally to the name and a description of the landmark, the following elements in order to fulfill this task: 95

96 CHAPTER 5. EXTENDING OPENLS PointPosition, LinePosition, AreaPosition For the exact geographic position of the landmark it can be chosen between this three elements. Which one is selected depends on the geometry of the landmark. The position is encoded as gml:pointtype, gml:linestringtype or gml:polygontype. SpatialRelation The attribute SpatialRelation contains the spatial relation between the described landmark and the destination of the route. The relation is encoded as a verbal expression. The possible relations are defined by the simple type EndLMRelationType. According to this a landmark sufficient to identify the destination of a route can be located next to the goal (left or right) or opposite to it. SideOfRoad Since the traveller is following a road, the landmark can be locate either on the right side of the road, the left side or on both. This information is stored in this optional attribute. <<Abstract>> AbstractLandmarkType +Name: String LMClass <<Abstract>> AbstractDescriptionLMType <<Abstract>> AbstractNElementLMType <<Abstract>> Abstract1ElementLMType StartPointLMType EndPointLMType AreaLMNType <<Abstract>> LinearLikeLMType PolygonPosition gml:polygontype cf. GML-specification SideOfRoad <<Enumeration>> SideOfRoadType +Left +Right +Both SideOfRoad NotIdentifyingLLMType Landmark <<Abstract>> Abstract1EDPLMType LinePosition gml:linetype cf. GML-specification LinePosition AreaPosition gml:polygontype cf. GML-specification AreaPosition IdentifyingLLMType SpatialRelation <<Enumeration>> SpatialRelationLinearIdentType PointPosition gml:pointtype PointPosition cf. GML-specification SpatialRelation LinePosition gml:linetypetype cf. GML-specification +along +after SpatialRelation <<Enumeration>> StartLMRelation <<Enumeration>> EndLMRelation Orientation gml:compasspointenumeration cf. GML-specification Figure 5.7: Data structure representing n Elements landmarks, StartingPoint- LMType and EndPointLMType AbstractNElementLMType Landmarks related to more than one route element are represented by the abstract class AbstractNElementLMType (cf. Fig 5.5.2). Two child classes for the two 96

97 5.5. INTEGRATION OF LANDMARKS IN OPENLS required sub categories are introduced. AbstractLineLMType stores information on landmarks conceptualised as linear and AreaLMNType those conceptualised as areal. AreaLMNType Area landmarks identifying a chunk of route elements are represented by the complex type AreaLMNType. Since areal landmarks identifying several route elements are not further specified, this type is not abstract. Areal landmarks require different attributes/elements as for landmarks with a similar purpose (e.g., line landmarks). The element is: PolygonPosition For giving the position of the landmark a polygon is provided in this element. The polygon is encoded according to the GML specification as a gml:polygontype. The spatial relation of a landmark to the related decision point is always around. Hence, it is implicitly encoded in the complex type AreaLMNType. AbstractLineLMType Landmarks with a linear function are located along the route and are therefore related to more than one element of the route. Since it is distinguished between different types linear landmarks (identifying the last decision point or not) an underlying abstract type, the AbstractLinearLikeLMType is introduced, which covers with its attributes and elements the characteristic common for all type of landmarks with a linear function. AreaPosition, LinePosition For the exact position of the landmark it can be chosen between these two elements. Depending on the geometry of the landmark, the position is encoded as gml:polygontype or gml:linestring- Type. IdentifyingLLType The crucial part of describing the course of a route with a landmark with linear characteristics is the point where the route stops following the course of the landmark. The category of landmarks, which are significant at this point, do not need additional information to enable the traveller identifying this point. It is sufficient to identify the last decision point at which this relation ends by providing the spatial relation to each route element. SpatialRelation This spatial relation is described by the attribute SpatialRelation, which is of the simple type SpatialRelationLinearIdentType. This type enumerates the possible relations between the landmark and the route, which are along or after. 97

98 CHAPTER 5. EXTENDING OPENLS NotIdentifyingLLType Linear objects along the route, which are able to describe the course of the route due to their geometry but are not sufficient to specify where the route stops following this course are described by the complex type NotIdentifyingLLLType. Since the landmark does not identify the end of its common course with the route, additional information has to be provided describing this end point. For this purpose these line landmarks contain an additional point landmark. Landmark The point where the course of the route stops following the course of the linear landmark is in this case, where the landmark itself is not sufficient, described by an additional landmark with a point-like function. Therefore, the element Landmark provides the required additional information encoded as the complex type AbstractPointLMType. This type is described later in this chapter Abstract1ElementLMType The category of landmarks related to a single element of the route is divided into two sub categories: point landmarks and area landmarks. The proposed data structure contains a class for the category 1 element the abstract complex type Abstract1ElementLMType, which has two child classes for the two sub categories (cf. Fig ). Abstract1EDPLMType The abstract complex type Abstract1EDPLLMType represents the super type for all landmarks identifying only one decision point. In this point the extension does not stick to the taxonomy of landmarks outlined in section 2.2. Introducing this type allows for introducing in the type XManeuverType only one element (of an unbounded number) for all possible types of landmarks. However, since these sub categories have no common attributes or elements apart from those common for all landmarks, Abstract1EDPLMType has no additional attributes or elements. AreaLM1Type Landmarks with an areal function are represented by the complex type Area- LM1Type. It is derived from the type Abstract1EDPLLMType. Identifying a single decision point located within the landmark itself requires different attributes/elements than for landmarks with a similar purpose (e.g., point landmarks). Therefore, the introduced element is: PolygonPosition For giving the position of the landmark a polygon is provided in this element. The polygon is encoded according to the GML specification as a gml:polygontype. 98

99 5.5. INTEGRATION OF LANDMARKS IN OPENLS The spatial relation of a landmark to the related decision point is always in. Thus, it is implicitly encoded in the complex type AreaLM1Type. StructureLMType As discussed in section 2.2 the spatial configuration of an intersection can be salient enough to function as a point-like landmark. Therefore, the complex type StructureLMType is introduced providing the information necessary for the identification of the landmark. Intersection The information about the intersection itself is already contained in the element JunctionCategory of the element of the type XManeuverType representing an instruction at a decision point. In order to keep this data structure easily usable and to point out that this information must be used here again, the same element of the type JunctionCategory is contained again in the element Intersection, even though this results in providing redundant data. StreetNameLMType Roads identified by its street name can function as point like landmarks (cf. section 2.2). They are represented by the complex type StreetNameLMType, which provides the required information the traveller needs in order to identify the particular road at the decision point. Since the name of the landmark is already contained in the super type AbstractLandmarkType, this type adds only the following attribute: PositionAtIntersection This attribute of the type gml:angletype gives the angle of the branch of the intersection functioning as a landmark with respect to the branch on which the traveller arrives at the intersection. GSOLMType All other landmarks with a point like function which do not belong to the categories described above, are represented by the complex type GSOLMType. It describes a general salient object in the environment and provides attributes and elements containing general information about the appearance of such an object. PointPosition, LinePosition, AreaPosition A GSO can have an areal, linear or point like geometry. Therefore, there is the choice between different ways to encode the geographic location. The position is encoded either as gml:pointtype, as gml:linestringtype or as gml:polygontype. 99

100 100 Figure 5.8: Data structure representing 1 Element landmarks. AreaLM1Type PolygonPosition gml:polygontype cf. GML-specification <<Abstract>> Abstract1EDPPLMType StructureLMType Intersection <<Abstract>> AbstractJunctionType <<Abstract>> AbstractLandmarkType +Name: String <<Abstract>> Abstract1ElementLMType <<Abstract>> AbstractDPPLLMType StreetNameLMType GSOLMType SpatialRelation LMClass <<Enumeration>> SpatialRelationNonDPType +pass +cross +through PointPosition LinePosition PolygonPosition <<Abstract>> AbstractDescriptionLMType gml:pointtype cf. GML-specification gml:linestringtype cf. GML-specification gml:polygontype cf. GML-specification <<Enumeration>> SpatialRelationGSOType SpatialRelation PointPosition LinePosition PolygonPosition NonDPPLMType CHAPTER 5. EXTENDING OPENLS gml:angletype cf. GML-specification PositionAtIntersection +at +after +before

101 5.5. INTEGRATION OF LANDMARKS IN OPENLS SpatialRelation This attribute gives the spatial relation of the described object to the related route segment. Thus, it is of the simple type SpatialRelationGSOType, which lists all possible spatial relations (cf. section 2.2) identified by a verbal label (cf. figure 5.9). before after at Figure 5.9: Possible spatial relations between a point landmark and a decision point. NonDPPLMType For point landmarks located at route segments the type NonDPPLMType derived from Abstract1ElementLMType is introduced. It provides the following attribute and element: PointPosition, LinePosition, AreaPosition As in the other types representing landmarks which can have different geometries, there is the choice between different ways to encode the geographic location. The position is encoded either as gml:pointtype, as gml:linestringtype or as gml:polygontype. SpatialRelation The possible spatial relations are provided by this attribute encoded as SpatialRelationNonDPType. Depending on the geometry of landmark, the relation can be pass, cross or through Description of Landmarks As discussed in section 2.2, it is necessary for using landmarks properly in route instructions to describe the landmark. The traveller has to be informed what kind of salient object is used as the landmark and its appearance has to be described as far as it is necessary to identify the object unambiguously. All this necessary information has to be provided in the landmark elements. Since this part of the OpenLS navigation service tries to deliver the requested data independent from the final generated instruction, the information for describing a landmark has to be encoded independent from constraints such as actual verbal description. Presently this has not yet been sufficiently solved current research and integrating this extension would be outside the scope of this work. Hence, the only 101

102 CHAPTER 5. EXTENDING OPENLS element which is a not further specified added to the types of landmarks, which can be used in the future for this purpose. Here, only a short sketch of a possible solution is outlined to define a non abstract type for generating example documents based on the proposed extension. PictureData In order to enable the traveller to identify the used landmark a picture showing the landmark can be helpful. Thus, the optional element PictureData is provided. Thereby the picture is encoded as a string according to base64, a binary to text encoding scheme defined in the IETF (Internet Engineering Task Force) standard for Multipurpose Internet Mail Extensions [10]. This scheme for encoding binary data in a string is also used in other parts of the OpenLS specification. PictureURL Apart from the picture itself, also an Internet address can be provided linking to the Internet location of a picture showing the landmark. The URL (Uniform Resource Locator) is encoded as a simple string. This element can be used as an alternative to PictureData or additionally for making more pictures available. InfoURL In order to allow the service to provide more information about a landmark, an URL can be provided in the attribute InfoURL. The Internet address is encoded as a simple string and links to an Internet page containing additional information about the landmark. 5.6 Subsuming route directions Spatial chunking allows to reduce the number of the given route directions and by building up a hierarchy, subsumes instructions to focus the travellers with only essential information. Since chunking is not implemented in the original version of the OpenLS Navigation Service, the proposed extension adds the necessary types and adapts the data structure accordingly. To enable the usage of chunking in OpenLS according to the work of Klippel [24] and Dale [5], several changes in the design of the data structure described in XLS have to be made. The possibility to subsume a sequence of directions in one single instruction has to be introduced to allow spatial chunking. To build up a hierarchy in the provided route directions, it is also necessary to offer attributes and elements which relate the route directions to each other. A travel maneuver that summarises more than one decision point has to be recognisable for the users as a higher order route segment. Thus, they know that there is more detailed information accessible if the summarised direction is not sufficient for them. Hence, such an instruction has to contain all the information about each subsumed decision point, in order that it is not necessary to contact the server for requesting more specific instructions. 102

103 5.6. SUBSUMING ROUTE DIRECTIONS For the internal data structure, it is helpful if higher order route segments can be used in the same way as any usual elementary instruction. This allows the combination of chunks of different levels in one segment. For example, a list of instructions can consists of chunks and elementary directions on the same level of the built up hierarchy. Also, an elementary route direction can be chunked together with an instruction that already subsumes several other elementary route directions. Besides segmenting directions on a higher level to build up a hierarchy, also chunking of elementary route direction elements has to be implemented. For each possible chunking type (e.g. based on the different types of landmarks) the necessary attributes and elements, which allow for indicating the end of a chunk and to describe the required actions, have to be introduced ChunkType To achieve this aim, the ComplexType ChunkType is introduced which is derived from AbstractManeuverType. An element of this type provides all information for describing a summarising route segment and additionally all information about the summarised directions. Being derived from AbstractManeuverType has the advantage that it can be used as a normal direction and contains the same elements and attributes as an usual direction, but also provides additional attributes and elements. The type ChunkType extends AbstractManeuverType by the number of combined directions, a list of this directions, an optional street name and the ChunkingElement. NumberOfPassedDP This attribute provides the information of how many decision points the traveller has to perform the described instruction. It is essentially for numerical chunking where it is the basic information. But it can also be used for other types of chunking as additional information for supporting the identification of the end of the segment. ChunkedManeuver This element provides a list of the subsumed instructions as elements of the type AbstractManeuverType. Each element of this list represents one of the summarised directions and the corresponding information. Since the type ChunkType is derived from AbstractManeuverType, the list can also contain again an object of the type ChunkType. This allows to build a recursive hierarchy. The structure of the hierarchy is not constrained. Since each single subsumed instruction is still available in this list, including all information necessary for its description, it is possible to generate more detailed and less chunked route directions from this data set without contacting the sever again, if it is requested by the user. 103

104 CHAPTER 5. EXTENDING OPENLS <<Abstract>> AbstractManeuverType 2..* +id: ID required +junctionname: String optional +numberexitstopass: nonnegativeinteger optional +ManeuverPoint: gml:pointtype +_NextSegment: RouteSegmentExtendedType minoccurs=0 +actiontype: RouteActionType required +directionofturn: TurnDirectionType optional +junctiontype: JunctionCategoryType optional ChunkedManeuver ChunkType +NumberOfPassedDP: positiveinteger +Streetname: string optional ChunkingElement ChunkingElement <<Abstract>> AbstractChunkingElementType ChunkingElement RoadHierarchyChunkType +LevelName: string NElementMChunkingType <<Abstract>> StructureChunkType PointLMChunkingType ChunkingLM +TIntersection: TIntersectionType Choice +ForkIntersection: ForkIntersectionType Choice +SRoundabout: SmallRoundaboutType Choice +LRoundabout: LRoundaboutType Choice ChunkingLM Abstract1EDPPLMType AbstractNElementLMType NumericalChunkingStraightType NumericalChunkingTurnType TurnDirectionAtLastDP ChunkDirection +Right +Left <<Enumeration>> TurnDirectionTypeChunk Figure 5.10: Data Structure supporting Chunking. 104

105 5.6. SUBSUMING ROUTE DIRECTIONS Streetname The additional information provided by this attribute is simply the name of the street, which is used to subsume a sequence of decision points along the road. Street name chunking always requires an additional element to indicate the end of the chunk. For specifying the end of such a chunk, the other chunking element, which is always part of a ChunkType element, can be used. ChunkingElement To indicate unambiguously the last decision point of a sequence, an element of the type AbstractChunkElement is part of each chunk. Therefore, each object contains an element of the type Abstract- ChunkElement. LastIntersection Even though the last instruction of a chunk provides the category of the last intersection and the required turn, a ChunkType contains an element of the type AbstractJunctionCategoryType. Since the same element is part of the chunking element StructureChunkType, which is discussed later, this element is optional to avoid further redundancy. This elements defines the type of chunking, which is used to create this subsuming instruction. For each single type of chunking, one derivated from AbstractChunkElement type exists, which contains the necessary information and indicates the type of chunking. The structure of an element of the type AbstractChunkElement is explained in the next section AbstractChunkElement For each possibility to indicate the last decision point of a sequence of subsumed route directions, an element of a different type is used. The introduced types provide all information for the according kind of chunking necessary. The segmentation based on the name of the road is integrated in the other chunking methods, since its usage always needs a special element for indicating the last decision point, similar to the other types of chunking. StructureChunkType If the structure of an intersection is used to indicate the end of a chunk, the chunking element StructureChunkType is used. It contains either an element of the type TIntersectionType, ForkIntersectionType, LargeRoundaboutType or SmallRoundAboutType. The other categories of intersections are not salient enough. RoadHierarchyChunkType For the usage of road hierarchy chunking, the level of the current road segment must be indicated. Since it differs depending, for example, on the country (the 105

106 CHAPTER 5. EXTENDING OPENLS administrative road hierarchy can vary in different countries) and the actual type of hierarchy (e.g., an official hierarchy or just a street where you have always the right of way), the used hierarchy cannot be predetermined. Thus, it is practically impossible to regard all possibilities for the hierarchy of the current street network. Therefore, an element of the type RoadHierarchy contains a String LevelName, which is supposed to provide the official name of the current road hierarchy level. An element of the type RoadHierarchy contains again an AbstractChunkElement (ChunkingElement) to indicate the end of the segment. NumericalChunkingTurnType Elements of this type are used to indicate the usage of numerical chunking. The information, which is needed for describing an instruction based on type of chunking, is mainly already provided by the corresponding AbstractChunkElement, because it can also be used for other types of chunking as supporting information. Therefore, this type contains only additional information of the turn (TurnDirection) since the directional change has to be similar at each of the subsumed decision points. NumericalChunkingStraightType Apart from the missing TurnDirection this type is identical with NumericalChunkingTurnType. It indicates the chunking of several decision point without directional change. PointLMChunkingType For using a point landmark as chunking element and thus a landmark based chunking, a chunking element of this type is used. The only element it contains is the landmark object of the type Abstract1EDPLMType. NElementLMChunkingType For the chunking method based on n Elements landmarks, a special type is derived from AbstractChunkElement. As the PointLMChunkingType it contains a landmark, but of the type AbstractNElementLMType. If the landmark is not sufficient to identify the end of the chunk, additionally, another chunking element can be provided. Therefore, chunking with a n Elements landmark can, for example, be combined with PointLMChunkingType or even numerical chunking. 5.7 Summary This chapter proposes an extension of the OpenLS Navigation Service that regards aspects of cognitive ergonomic route directions. Based on a Navigation Re- 106

107 5.7. SUMMARY sponse using the new data model, the client is able to generate route directions, that are easier to understand for travellers and provide additional knowledge about the environment. The aspects regarded are: More precise direction concepts by providing the structure of the intersection in combination with a direction concept that is adequate for the type of intersection. Landmarks are integrated for an easier identification of route elements and a better description of the required action. Subsuming route directions to reduce the cognitive load of route instructions and provide travellers only with the essential and necessary information, but also to make additional and more detailed information accessible. 107

108

109 6 Usage of the proposed data structure The implementation of a client and a server supporting the proposed data structure is not part of this thesis. However, it would be necessary to proove that the described extension fulfills its tasks and is able to store the required information to produce cognitive ergonomic route directions. In this chapter it is shown that the data structure can encode the information derived from a calculated route, by three hand coded examples using the new version of XLS. All examples are based on real situations, but the used data is not based on a real data set. For creating them, a route was calculated by the navigation service and interpreted manually that was then finally encoded in the new version of XLS. Due to this method of generating the required data, there was no geospatial data available and thus, no exact angular information; all elements storing geographic coordinates are set on dummy values. However, this is irrelevant for this examination since the focus of this work is not on geo referencing. Only the first example covers the description of a whole route. All others focus on a certain aspect and thus, contain only selected elements of the XLS-code. For each example route instructions are also given in order to demonstrate, how the final instructions could look like. These directions are not based on any natural language generation techniques. All pictures used in this chapter are based on maps generated by map24.com in March Example 1: A complete route The first example is the only one that covers a complete route from the starting point to the end point. It is based on a real route calculated by the navigation service The examined route starts Ronzelenstrasse 18, Bremen and ends at the Ortsamt Horn-Lehe (Berckstrasse 10, Bremen). It comprises instructions for the beginning and the end of the route, a chunk using numerical chunking, four point landmarks and the basic features of a route (e.g., a simple maneuver). Each XLS file starts with a header defining the name space and the other included XML-schemas. The extended version of XLS needs to include the schema- 109

110 CHAPTER 6. USAGE OF THE PROPOSED DATA STRUCTURE Riensberger Str. Leher Heerstr. Horner Kirche Horner Heerstr. Berckstrasse 10 LESTRA Berckstr. Ronzelenstrasse 18 Ronzelenstr. Figure 6.1: Map of the route in example 1 from Ronzelenstrasse 18, Bremen to Berckstrasse 10, Bremen. Based on map from from March

111 6.1. EXAMPLE 1: A COMPLETE ROUTE file ADT NavXtension.xsd. 1 <?xml version= 1. 0 encoding= UTF 8?> 2 <xls:xmaneuverlist xmlns:xls= http: //www. opengis. net/ xls xmlns:sch= http: //www. ascc. net/xml/schematron xmlns:gml= http: //www. opengis. net/gml xmlns:xlink= http: // org /1999/ xlink xmlns:xsi= http: // org /2001/ XMLSchema instance xsi:schemalocation= http: //www. opengis. net/ xls 3 D:\xml\ ols1 1 \05 016\ADT NavXtension. xsd > The description of the route starts with a chunk subsuming the two decision points of the route. The starting and the end maneuver can be found at the end of the maneuver list. The xls:maneuverpoint gives the location of the last decision point of the chunk. 4 <xls:chunkmaneuver i d= chunk1 actiontype= Advisory NumberOfPassedDP= 2 > 5 6 <xls: ManeuverPoint> 7 <gml: pos> </ gml: pos> 8 </ xls: ManeuverPoint> The first of the chunked maneuver describes the action the traveller has to perform at a T intersection. This intersection is also used as a structural landmark, even though it means that the information about the junction is encoded twice. 9 <xls:chunkedmaneuver x s i: t y p e= xls:xmaneuvertype actiontype= Turn i d= dp1 directionofturn= Right junctiontype= Intersection > 10 <xls: ManeuverPoint> 11 <gml: pos> </ gml: pos> 12 </ xls: ManeuverPoint> 13 <xls:junctioncategory xsi:type= xls:tintersectiontype TurnDirection= right > 14 <xls:routebranch Streetname= Horner Heerstrasse > 15 <xls:angle uom= degree >90</ xls:angle> 16 </ xls: RouteBranch> 17 <xls:noroutebranch Streetname= Horner Heerstrasse > 18 <xls:angle uom= degree >270</ xls:angle> 19 </ xls:noroutebranch> 20 </ xls:junctioncategory> 21 <xls:landmark xsi:type= xls:structurelmtype > 22 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description> 23 <x l s : I n t e r s e c t i o n xsi:type= xls:tintersectiontype TurnDirection= right > 24 <xls:routebranch Streetname= Horner Heerstrasse > 25 <xls:angle uom= degree >90</ xls:angle> 26 </ xls: RouteBranch> 27 <xls:noroutebranch Streetname= Horner Heerstrasse > 28 <xls:angle uom= degree >270</ xls:angle> 29 </ xls:noroutebranch> 30 </ x l s : I n t e r s e c t i o n> 31 </ xls:landmark> 32 <xls:previoussegment Streetname= Ronzelenstrasse > 111

112 CHAPTER 6. USAGE OF THE PROPOSED DATA STRUCTURE 33 <xls:distance value= 10 ></ xls:distance> 34 <xls:traveltime>p1y2m3dt10h30m12.3s</ xls:traveltime> 35 <xls:boundingbox> 36 <gml: pos> </ gml: pos> 37 <gml: pos> </ gml: pos> 38 </ xls:boundingbox> 39 </ xls:previoussegment> 40 </ xls:chunkedmaneuver> <xls:chunkedmaneuver x s i: t y p e= xls:xmaneuvertype actiontype= Turn i d= dp2 directionofturn= Right junctiontype= Intersection > 43 <xls: ManeuverPoint> 44 <gml: pos> </ gml: pos> 45 </ xls: ManeuverPoint> 46 <xls:junctioncategory xsi:type= xls:standardintersectiontype TurnDirection= right > 47 <xls:routebranch Streetname= Berckstrasse > 48 <xls:angle uom= degree >90</ xls:angle> 49 </ xls: RouteBranch> 50 <xls:noroutebranch Streetname= Riensberger Strasse > 51 <xls:angle uom= degree >270</ xls:angle> 52 </ xls:noroutebranch> 53 <xls:noroutebranch Streetname= Leher Heerstrasse > 54 <xls:angle uom= >0</ xls:angle> 55 </ xls:noroutebranch> 56 </ xls:junctioncategory> The second of the chunked decision points is identified by church, which functions here has a GSO/point landmark. The landmark is also integrated in the description of the required turn, since the travellers have to perform a directional change after they passed the church. 61 <xls:landmark x s i: t y p e= xls:gsolmtype Name= Horner Kirche SpatialRelation= after > 62 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description> 63 <xls:pointposition> 64 <gml: pos> </ gml: pos> 65 </ xls:pointposition> 66 </ xls:landmark> 67 <xls:previoussegment Streetname= Horner Heerstrasse > 68 <xls:distance value= 10 ></ xls:distance> 69 <xls:traveltime>p1y2m3dt10h30m12.3s</ xls:traveltime> 70 <xls:boundingbox> 71 <gml: pos> </ gml: pos> 72 <gml: pos> </ gml: pos> 73 </ xls:boundingbox> 74 </ xls:previoussegment> 75 </ xls:chunkedmaneuver> The chunking element for this chunk has to provide the type of chunking (this is implicitly done by its type) and the directional change at the chunked turns. The number of subsumed elements is given at the beginning as an attribute of 112

113 6.1. EXAMPLE 1: A COMPLETE ROUTE the chunk itself. The turn at the last decision point of the chunk is described by the element xls:lastintersection. The element xls:chunkedsegments contains the estimated travel time and distance for all chunked segments together <xls:lastintersection xsi:type= xls:standardintersectiontype TurnDirection= l e f t > 78 <xls: RouteBranch Streetname= Wilhelm Kaisen Bruecke > 79 <xls:angle uom= degree >270</ xls:angle> 80 </ xls: RouteBranch> 81 <xls:noroutebranch Streetname= Balgebrueckstrasse > 82 <xls:angle uom= degree >90</ xls:angle> 83 </ xls:noroutebranch> 84 <xls:noroutebranch Streetname= Martinistrasse > 85 <xls:angle uom= >0</ xls:angle> 86 </ xls:noroutebranch> 87 </ xls:lastintersection> <xls: ChunkingElement 90 xsi:type= xls:numericalchunkingturntype 91 TurnDirection= r i g h t ></ xls: ChunkingElement> <xls:chunkedsegments> 94 <xls:distance value= 10 ></ xls:distance> 95 <xls:traveltime>p1y2m3dt10h30m12.3s</ xls:traveltime> 96 <xls:boundingbox> 97 <gml: pos> </ gml: pos> 98 <gml: pos> </ gml: pos> 99 </ xls:boundingbox> 100 </ xls:chunkedsegments> </ xls:chunkmaneuver> The starting maneuver tries to give the traveller an orientation at the beginning of the route. In this case the absolute direction (West), the direction according to the address and the first route segment (that means the travellers stand in front of the location facing the start of the route segment; in this case they have to turn right) and a landmark. Since there is no better object available, that could function in this case as landmark, just the next road the travellers are heading towards is used. 76 <xls:startingmaneuver id= Start Orientation= W RoadDirection= right > <xls:address countrycode= DE > 79 <xls:freeformaddress> 80 Ronzelenstrasse 10, Bremen (Horn Lehe) 81 </ xls:freeformaddress> 82 </ xls:address> <xls:position> 85 <gml: pos> </ gml: pos> 86 </ xls:position> 113

114 CHAPTER 6. USAGE OF THE PROPOSED DATA STRUCTURE <xls:landmark Orientation= W SpatialRelation= towards Name= Horner Heerstrasse > 89 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description > 90 <xls:pointposition> 91 <gml: pos> </ gml: pos> 92 </ xls:pointposition> 93 </ xls:landmark> </ xls:startingmaneuver> For describing the destination of the route a point landmark is given in the end maneuver. To inform the traveller about its location and relation to its destination, the absolute orientation and the side of the road the object is located on is given, both according to the travellers current position. Furthermore, the relationship between destination and landmark is provided (opposite. 76 <xls:endmaneuver i d= end SideOfRoad= L e f t > <xls:address countrycode= DE > 79 <xls:freeformaddress>berckstrasse 10, Bremen</ xls:freeformaddress> 80 </ xls:address> <xls:position> 83 <gml: pos> </ gml: pos> 84 </ xls:position> <xls:landmark Orientation= N Name= Lestra SideOfRoad= Right SpatialRelation= opposite > 87 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description > 88 <xls:pointposition> 89 <gml: pos> </ gml: pos> 90 </ xls:pointposition> 91 </ xls:landmark> <xls:previoussegment Streetname= Berckstrasse > 94 <xls:distance value= 12 ></ xls:distance> 95 <xls:traveltime>p1y2m3dt10h30m12.3s</ xls:traveltime> 96 <xls:boundingbox> 97 <gml: pos> </ gml: pos> 98 <gml: pos> </ gml: pos> 99 </ xls:boundingbox> 100 </ xls:previoussegment> </ xls:endmaneuver> </ xls: XManeuverList> The example shows the basic usage of the data model described in chapter 5 and some more advanced features. Since this example is supposed to demonstrate as 114

115 6.2. EXAMPLE 2: SPATIAL CHUNKING many of these features as possible, some of them would not be used in the generated route directions. For example, the church describing the turn at the second decision point would not be mentioned, since this turn is sufficiently described by the numerical chunk. If it is better to use the numerical chunk or the landmark in the generated route directions is still ongoing research. Possible route directions generated on the basis of this data set are, for example: 1. Starting at Ronzelenstarsse 18, turn right into Ronzelenstrasse towards Horner Heerstrasse. 2. Turn twice right. 3. Following Berckstrasse, you arrive at Berckstrasse 10 located on your left hand side opposite Lestra.) 6.2 Example 2: Spatial chunking The second example demonstrates chunking along a linear landmark and chunking using road hierarchy. The chunk along the landmark is subsumed in the other chunk together with a third chunk. After turning on the road Osterdeich, which is also called B75, the route leads along the river Weser until the bridge Wilhelm-Kaisen-Bruecke, which functions here as a point-like landmark, is reached. The road is still part of the B75, even though the street name had changed while following the river to Tiefer. After the bridge the street is called Friedrich-Ebert-Strasse, but the travellers are still on the B75. They leave it when they turn on to Kornstrasse at the end of the chunk. This second part of the chunk combining the roads belonging to the B75 can also subsumed using numerical chunking. The example starts with the first chunk, which subsumes the two other chunks. Like other parts of the code and add nothing to the example, that was not already in the first example, the position of the last decision point was replaced by [...]. The first chunked maneuver is already the other chunk, which subsumes also 9 maneuvers. 1 <xls:chunkmaneuver i d= C1 actiontype= Advisory NumberOfPassedDP= 2 > 2 3 [... ] 4 5 <xls:chunkedmaneuver x s i: t y p e= xls:chunktype i d= C2 actiontype= Advisory NumberOfPassedDP= 9 > 6 7 [... ] 8 9 <xls:chunkedmaneuver x s i: t y p e= xls:xmaneuvertype actiontype= Turn i d= M2 directionofturn= Straight junctiontype= Intersection > 10 [... ] 115

116 CHAPTER 6. USAGE OF THE PROPOSED DATA STRUCTURE Martinistr. Wilhelm Kaisen Bruecke Tiefer B75 Friedrich Ebert Str. B75 Osterdeich Berliner Str. Kornstr. Figure 6.2: Map of the route in example 2. It is based on a map provided by in March

117 6.2. EXAMPLE 2: SPATIAL CHUNKING 11 </ xls:chunkedmaneuver> [... ] <xls:chunkedmaneuver x s i: t y p e= xls:xmaneuvertype actiontype= Turn i d= M10 directionofturn= Left junctiontype= Intersection > 16 [... ] 17 </ xls:chunkedmaneuver> As chunking landmark, a n element landmark, the river Weser, is used. Since it is not sufficient to identify the end of the chunk, it contains an additional point landmark, a bridge, which is located at the last decision point of the chunk. The second of the two chunks subsuming eight intersections uses again numerical chunking. Since this is already demonstrated in the first example, it is not listed in detail. 17 <xls: ChunkingElement x s i: t y p e= xls:nelementlmchunktype > 18 <xls:chunkinglm xsi:type= xls:notidentifyinglltype Name= Weser > 19 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description> 20 <xls:lineposition> 21 <gml: pos> </ gml: pos> 22 <gml: pos> </ gml: pos> 23 </ xls:lineposition> 24 <xls:landmark xsi:type= xls:gsolmtype SpatialRelation= at Name= Wilhelm Kaisen Bruecke > 25 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description> 26 <xls:pointposition> 27 <gml: pos> </ gml: pos> 28 </ xls:pointposition> 29 </ xls:landmark> 30 </ xls:chunkinglm> 31 </ xls: ChunkingElement> <xls:lastintersection xsi:type= xls:standardintersectiontype TurnDirection= l e f t > 34 [... ] 35 </ xls:lastintersection> <xls:chunkedsegments> 38 [... ] 39 </ xls:chunkedsegments> </ xls:chunkedmaneuver> <xls:chunkedmaneuver x s i: t y p e= xls:chunktype i d= C3 actiontype= Advisory NumberOfPassedDP= 8 > 44 [... ] </ xls:chunkedmaneuver> The chunking element of the type xls:roadhierarchychunktype requires an ad- 117

118 CHAPTER 6. USAGE OF THE PROPOSED DATA STRUCTURE ditional chunking element which identifies the end of the chunk. In this case, simply the name of the next street has been chosen. However, if appropriate, numerical chunking could also have the same function. 52 <xls: ChunkingElement x s i: t y p e= xls:roadhierarchychunktype LevelName= B75 > 53 <xls: ChunkingElement x s i: t y p e= xls:pointlmchunktype > 54 <xls:chunkinglm xsi:type= xls:streetnamelmtype Name= Kornstrasse > 55 <xls:description xsi:type= xls:lmdescriptionexampletype ></ xls:description> 56 <xls:positionatintersection uom= deg >90</ xls:positionatintersection> 57 </ xls:chunkinglm> 58 </ xls: ChunkingElement> 59 </ xls: ChunkingElement> <xls:chunkedsegments> 62 [... ] 63 </ xls:chunkedsegments> </ xls:chunkmaneuver> Route directions comprising the segments and decision points along the B75 would contain on the highest level only one instruction describing the chunk along the B75. This instruction generated on the basis of this XLS code could, for example, be: Follow B75, till you reach Kornstrasse and turn left into Kornstrasse. Follow the river and turn left at Wilhelm-Kaisen-Bruecke. Turn left into Kornstrasse at the eighth intersection. On the intermediate level the route consists of two chunks which are represented by two instructions. The question, if the instruction describing the second chunk is too confusing with eight intersections, must be answered by future evaluations. 6.3 Example 3: Competing branches The last example contains a single maneuver describing the action at a complex intersection with competing branches. The same example has been used in section 3.1. The out going branch of the route competes on the right side with another road. Therefore, an ordering concept has to be introduced. In the element xls:junctioncategory, an ordering concept is used that tries to describe the turn unambiguously. The travellers are told to take the second exit (passing one exit) on their right. Additionally the exact configuration of the route is provided to give the travellers an exact picture of the spatial configuration. 118

119 6.3. EXAMPLE 3: COMPETING BRANCHES Ostheimer Str. Ruegheimer Str. Ringstr. Poststr. Obere Torstr. Figure 6.3: Map of the route in example 3. It is based on a map provided by in March <xls:xmaneuver i d= x actiontype= Turn directionofturn= Right junctiontype= Intersection > 2 3 <xls: ManeuverPoint> 4 <gml: pos> </ gml: pos> 5 </ xls: ManeuverPoint> 6 7 <xls:junctioncategory xsi:type= xls:competingbranchestype numberexitstopass= 1 TurnDirection= right > 8 9 <xls: RouteBranch Streetname= Ruegheimer S t r a s s e > 10 <xls:angle uom= degree >130</ xls:angle> 11 </ xls: RouteBranch> 12 <xls:noroutebranch Streetname= Poststrasse > 13 <xls:angle uom= degree >45</ xls:angle> 14 </ xls:noroutebranch> 15 <xls:noroutebranch Streetname= Ostheimer S t r a s s e > 16 <xls:angle uom= degree >190</ xls:angle> 17 </ xls:noroutebranch> 18 <xls:noroutebranch Streetname= Ringstrasse > 19 <xls:angle uom= degree >280</ xls:angle> 20 </ xls:noroutebranch> </ xls:junctioncategory> <xls:previoussegment Streetname= Obere Torstrasse > 25 <xls:distance value= 10 ></ xls:distance> 26 <xls:traveltime>p1y2m3dt10h30m12.3s</ xls:traveltime> 27 <xls:boundingbox> 28 <gml: pos> </ gml: pos> 119