9512.net
甜梦文库
当前位置:首页 >> >>

Universitt Bremen Acknowledgements


Cognitive OpenLS Specification
Stefan Hansen, Alexander Klippel, Kai-Florian Richter

SFB/TR 8 Report No. 012-10/2006 Report Series of the Transregional Collaborative Research Center SFB/TR 8 Spatial Cognition Universit?t Bremen / Universit?t Freiburg

Contact Address: Dr. Thomas Barkowsky SFB/TR 8 Universit?t Bremen P.O.Box 330 440 28334 Bremen, Germany Tel +49-421-218-64233 Fax +49-421-218-98-64233 barkowsky@sfbtr8.uni-bremen.de www.sfbtr8.uni-bremen.de

? 2006 SFB/TR 8 Spatial Cognition

Cognitive OpenLS Specification
October 18, 2006

Stefan Hansen,
CRC-Spatial Information, University of Melbourne / LISAsoft, Melbourne

Alexander Klippel,
CRC-Spatial Information, Department of Geomatics, University of Melbourne

Kai-Florian Richter,
Transregional Collaborative Research Center SFB/TR 8 Spatial Cognition, Universit¨t Bremen a

Acknowledgements
This work results from a diploma thesis at Universit¨t Bremen that has been a jointly supervised by the Universities Bremen and Melbourne and is based on ongoing research at both sites. Cognitive OpenLS is currently being implemented at Spatial Information Systems Ltd. / LISASoft, Melbourne. This work has been supported by the Transregional Collaborative Research Center SFB/TR 8 Spatial Cognition, which is funded by the Deutsche Forschungsgemeinschaft (DFG), and by the Cooperative Research Centre for Spatial Information, whose activities are funded by the Australian Commonwealth’s Cooperative Research Centres Programme. OpenLS is a trademark of the Open Geospatial Consortium.

Contents

1 Introduction 2 OpenLS 2.1 The OpenLS framework . . . . . . . . . . . . . . . . . . . . . . 2.1.1 XML for location services . . . . . . . . . . . . . . . . . 2.1.2 The OpenLS services . . . . . . . . . . . . . . . . . . . . 2.2 Route directions with OpenLS . . . . . . . . . . . . . . . . . . 2.2.1 Route directions in the route service . . . . . . . . . . . 2.2.2 Route directions in the Navigation Service . . . . . . . . 2.3 Data structure of the Navigation Service . . . . . . . . . . . . . 2.3.1 NavigationResponse . . . . . . . . . . . . . . . . . . . . 2.3.2 Structure of the route directions . . . . . . . . . . . . . 2.3.3 Data type of a single instruction . . . . . . . . . . . . . 2.3.4 ManeuverType: Extending the AbstractManeuverType 3 Cognitive OpenLS 3.1 Approach . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Cognitively ergonomic route directions . . . 3.1.2 Additional Features . . . . . . . . . . . . . 3.1.3 Technical realisation . . . . . . . . . . . . . 3.2 Extending RouteManeuverList . . . . . . . . . . . 3.2.1 XStartingManeuverType . . . . . . . . . . . 3.2.2 XEndManeuverType . . . . . . . . . . . . . 3.3 XManeuverType . . . . . . . . . . . . . . . . . . . 3.3.1 Deriving from AbstractManeuverType . . . 3.3.2 Replacing NextSegment by CurrentSegment 3.4 Making route directions more precise . . . . . . . . 3.4.1 Direction model . . . . . . . . . . . . . . . 3.4.2 Naming the structure . . . . . . . . . . . . 3.4.3 Types representing intersections . . . . . . 3.5 Integration of landmarks in OpenLS . . . . . . . . 3.5.1 AbstractLandmarkType . . . . . . . . . . . 3.5.2 Landmarks for orientation at Start and End 3.5.3 AbstractNElementLMType . . . . . . . . . 3.5.4 Abstract1ElementLMType . . . . . . . . . 3.5.5 Description of Landmarks . . . . . . . . . . 3.6 Chunking Route Directions . . . . . . . . . . . . . 3.6.1 ChunkType . . . . . . . . . . . . . . . . . .

7 9 9 10 10 11 11 12 12 12 13 14 18 23 23 23 24 24 24 25 26 28 28 29 30 30 31 31 34 34 34 36 37 40 41 42

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

3

Contents 3.6.2 AbstractChunkElement . . . . . . . . . . . . . . . . . . . 44 47 47 52 55 57

4 Examples of Cognitive OpenLS 4.1 Example 1: A complete route . . . . . . . . . . . . . . . . . . . . 4.2 Example 2: Spatial chunking . . . . . . . . . . . . . . . . . . . . 4.3 Example 3: Competing branches . . . . . . . . . . . . . . . . . . 5 Schema

4

List of Figures

2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2

Data structure of a list of route maneuvers in OpenLS. . . . . . . Data structure of an abstract route maneuver in OpenLS. . . . . List of possible actions described in a route direction of OpenLS. Categories of intersections in OpenLS. . . . . . . . . . . . . . . . Possible directional changes in OpenLS. . . . . . . . . . . . . . . Data structure of an extended route maneuver in OpenLS. . . . .

14 15 16 17 18 19 25

Diagram of the extended data structure of a route maneuver list. This ?gure depicts the assumed position of the way?nder at the start of a route. To follow the route the way?nder has to turn right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Data structure of a start maneuver and an end maneuver. . . . . 3.4 The extended data structure of a route maneuver. . . . . . . . . 3.5 List of possible types of intersections. . . . . . . . . . . . . . . . . 3.6 Data structure of the di?erent types of intersections. . . . . . . . 3.7 Data structure representing n–Elements landmarks, StartingPointLMType and EndPointLMType. . . . . . . . . . . . . . . . 3.8 Data structure representing 1–Element landmarks. . . . . . . . . 3.9 Possible spatial relations between a point–landmark and a decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Data Structure supporting Chunking. . . . . . . . . . . . . . . . 4.1

26 27 29 31 32 36 39 40 42

4.2 4.3

Map of the route in example 1 from Ronzelenstrasse 18, 28359 Bremen to Berckstrasse 10, 28359 Bremen. Based on map from www.uk.map24.com from March 2006. . . . . . . . . . . . . . . . 48 Map of the route in example 2. It is based on a map provided by www.de.map24.com in March 2006. . . . . . . . . . . . . . . . 53 Map of the route in example 3. It is based on a map provided by www.de.map24.com in March 2006. . . . . . . . . . . . . . . . 56

5

1 Introduction
Research on way?nding and route directions in psychology, linguistics, and cognitive science provides ample evidence for principles of good route directions (e.g., [4, 15]). By analyzing human route directions those principles can be extracted that are most successful, in opposition to simply mimic human route direction. In this report we combine existing approaches and our own research. We identi?ed the following three principles that we consider essential for cognitively ergonomic route directions (cf. [7]; see also [13, 19]): ? Making direction concepts more precise: depending on the spatial structure of a decision point, describing the action to be performed may di?er [10, 11, 14]. For example, a change in direction usually described as “veer right” might turn to “fork right” given that the road ahead forks to the left and right (i.e. there are two possible branches to take, one heading o? to the left, one to the right at approximately 45 degrees). ? References to landmarks: landmarks are crucial for good route directions [4, 5, 17]. They are used, among others, to identify decision points, to link actions to be performed to decision points, and to provide con?rmation information that the correct route is still followed. ? Subsuming route directions: subsuming several directions for individual decision points into one higher order direction covering a sequence of decision points with a single instruction is the third important principle of cognitive ergonomic route directions [3, 12]. Examples of instructions employing this spatial chunking [12] are “turn left at the third intersection” and “follow the river until the gas station.” These principles need to be transformed into an adequate data structure to be able to represent the required information for automatically generating cognitively ergonomic route directions. With the Navigation Service the OpenLS speci?cation [16, 1] developed by the Open Geospatial Consortium [18] o?ers exactly the functionality required for this purpose. This service provides a client with the data necessary to generate route directions. In this document, we present the speci?cation of Cognitive OpenLS, a data structure that captures these principles, which is based on the OpenLS speci?cation. More details on the motivation, the empricial and computational justi?cation, and the general approach of this line of research can be found elsewhere in our publications, for example, in [7, 10, 14, 19]. In this document, we focus on the data structure itself, i.e. on the XML-speci?cation of Cognitive OpenLS. The document is structured as follows: in the next chapter we introduce the organization of OpenLS as de?ned by the OGC. Chapter 3 details how

7

CHAPTER 1. INTRODUCTION the cognitive principles required for cognitive ergonomic route directions are integrated in the OpenLS speci?cation, i.e. presents our extension to OpenLS; Chapter 4 shows some examples of specifying way?nding situations using Cognitive OpenLS. Chapter 5 then lists the XML schema that de?nes Cognitive OpenLS.

8

2 OpenLS
In this chapter, we detail the OpenLS speci?cation as provided by the OGC and its functionality. Generally, our work aims at integrating cognitive ergonomics and automatically generated route directions. The Open Location Services speci?cation [16, 1] o?ers an open interface to a location based server. Extending this approach with the aspects of spatial cognition as discussed in Chapter 1, allows for specifying a system capable of providing automatically generated route directions that adhere to principles of cognitive ergonomics.

2.1 The OpenLS framework
Location based services are usually provided over a network, which o?er 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 Geospatial Consortium proposed an implementation speci?cation, which describes the Open Location Services (OpenLS), also known as the GeoMobility Server (GMS). This standard speci?es an open platform for location based services. A Server implementing this platform according to the speci?cation can be accessed by any client that supports OpenLS. The OpenLS speci?cation 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 (ADTs) and the relationship of OpenLS to other speci?cations and standards. The provided services are described in Section 2.1.2. The OpenLS standard consists of a set of speci?cations of interfaces (de?ned as XML schemas), which determine access to the basic services of such a server and the abstract data types used in the documents that are exchanged between server and client. OpenLS de?nes primarily the interaction between client and server (request and response schemas) and the format in which the transfered data is encoded. This way, the functionality a server implementing OpenLS has to o?er are already implicitly de?ned. Since May 2005 OpenLS is available in version 1.1 with status ?nal. Recently the OGC has formed a group, which will develop the next version of the OpenLS speci?cation.

9

CHAPTER 2. OPENLS

2.1.1 XML for location services
The main part of the OpenLS speci?cation comprises the de?nition of the XMLbased markup language XML for Location Services (XLS). The documents de?ned as request and response schemas and exchanged in communication between client and a GMS are encoded in XLS. XLS is a markup language de?ned in a XML–schema. It de?nes the structure and application of the XML-documents, which are transfered as requests and responses for the client/server interaction, and it speci?es the abstract data types (ADTs) (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 discussed later in more detail. These are extended with the cognitive ergonomic aspects to become Cognitive OpenLS.

2.1.2 The OpenLS services
The basic service framework of a GeoMobility Server comprises the ?ve so– called core services. These services are described in [16]. In an additional document [1], a sixth service, the Navigation Service, is speci?ed. This Navigation Service does not belong to the core services. In the following section, the functionality of these service is brie?y described. Core services ? Part 1: Directory Service o?ers access to an online directory (such as the Yellow Pages). It allows for ?nding a speci?c or a nearest place, a requested product or service. ? Part 2: Gateway Service is an interface between a GMS and a Location Server for requesting the location of one or more mobile devices. ? Part 3: Location Utility Service (Geocoder/Reverse Geocoder) returns to a given position the complete normalized description of a feature location (place name, street address, postal code) or given a feature location (place, street or postal code) it provides the position and the complete normalized description. ? Part 4: Presentation Service The Presentation Service portrays a map based on any geographic information for display on a mobile terminal. ? Part 5: Route Service o?ers routes and additional navigation information. Navigation service The Navigation Service is an enhanced version of the Route Service. It is not part of the core services of the OpenLS speci?cation and is described in a separate document [1].

10

2.2. ROUTE DIRECTIONS WITH OPENLS The Navigation Service supports the same parameters as the Route Service and thus, o?ers the same functionality. Additionally, it extends the Route Service by adding special parameters for navigation purposes. This allows aclient providing a 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 used by OpenLS based applications to produce more speci?c and appropriate route directions.

2.2 Route directions with OpenLS
The OpenLS speci?cation o?ers two di?erent possibilities for providing route directions. The ?rst is based 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 possibility, which is only part of the Navigation Service, provides for each instruction a complex object. This can be used by a client to generate 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.

2.2.1 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 o?ers the subscriber several parameters for specifying the characteristics of the route (e.g., di?erent route preferences like fastest, shortest or most scenic route). Additionally to this overlay, the Route Service provides the user with simple route directions. A single direction in the Route Service 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 speci?c route directions, subscribers can indicate their preferred language. Optionally, the text-format of the directions can be set by a parameter. The default value is text/plain. Other options for setting this parameter are not speci?ed in the OpenLS standard. The route directions of the Route Service provide only verbal instructions. Multimodal directions including, for example, visualizations in form of pictograms describing the required action can only be generated by the accessing

11

CHAPTER 2. OPENLS application. They are not speci?cly supported by the transferred data. Therefore, the given route directions are, as far as the verbal instructions are concerned, not ?exible at all and a client cannot adapt them according to cognitive aspects. The verbal instructions are generated on the server and transferred as an (arbitrary) string. Based on this speci?cation, it is not possible to decide whether the provided route directions regard the aspects of cognitive ergonomic route directions discussed in Chapter 1. Furthermore, encoding instructions in simple strings might be su?cient for providing route directions respecting for some of the cognitive ergonomic aspects. However, this way it is impossible to ensure their integration in route directions presented to a user.

2.2.2 Route directions in the Navigation Service
The Navigation Service o?ers two possibilities of encoding route directions. Since it provides all parameters and all functions which are available in the Route Service, the ?rst possibility is the verbal route directions described in the previous section. The second possibility is the generation of complex objects that describe each route direction in more detail. The provided objects contain preprocessed information which are necessary for generating route directions. This information needs to be further processed by a client to be presentable to a human user. 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 can generate route directions that regard the users’ individual preferences and the technical constraints of the client system (e.g., display size or processing speed). The parameters and information provided by the Navigation Service in an XLS–element representing route directions are described in detail in the next section. The abstract data types and information provided by elements of these types are explained.

2.3 Data structure of the Navigation Service
As already mentioned, in OpenLs communication between client and server is realized as request and response pairs. In this section, we detail the data structure and parameters of a Navigation Response. We focus on the elements required to generate route directions on the client side.

2.3.1 NavigationResponse
For each service exists a request / response pair speci?ed as a XML-schema. In the following, alle elements of a NavigationResponse are explained. The focus is placed on the response for a requested list of travel maneuvers.

12

2.3. DATA STRUCTURE OF THE NAVIGATION SERVICE NavigateResponseType The document containing a server’s 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 speci?c 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 speci?c 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 speci?ed. 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-byturn route instructions. It encodes the instructions according to the route directions used in the Route Service (cf. Section 2.2.1). The use of this element is optional. RouteMap Each of these optional elements contain a map of a requested area. The map is transferred as a binary image encoded as base64 [8]. The number of provided maps is unbound. RouteManeuverList The RouteManeuverList contains the route directions generated according to the more complex method used in the Navigation Service. The use of this element is optional.

2.3.2 Structure of the route directions
The more complex route directions o?ered 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. 2.1) is described in the following: AbstractRouteManeuverListType This abstract type is the parent type of RouteManeuverListType, which is used for storing route directions. It represents a simple list of so–called travel

13

CHAPTER 2. OPENLS 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 of Manuever elements, with every element representing a single maneuver. The Manuever elements in the list are of the type AbstractManeuverType that speci?es a single travel maneuver.
<<Abstract>>

AbstractRouteManeuverList
_Manuever

1..*

RouteManeuverListType
+id: ID

<<Abstract>>

AbstractManeuverType required

<<simpleType>>

+junctionName: String maximumRoadClass

positiveInteger

optional
+numberExitsToPass: nonNegativeInteger

optional
<<simpleType>> 0..1 +ManeuverPoint: gml:PointType +_NextSegment: RouteSegmentExtendedType

RoadClassType

minOccurs=0
+actionType: RouteActionType

required
+directionOfTurn: TurnDirectionType

optional
+junctionType: JunctionCategoryType

optional

Figure 2.1: Data structure of a list of route maneuvers in OpenLS.

RouteManeuverList The NavigationResponse for a requested navigation service provides a RouteManeuverList. For each decision point along the route there is one instruction 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 RouteManeuverListType, which is an extension of AbstractRouteManeuverListType and provides all parameters of its parent. The extension adds the optional attribute maximumRoadClass (RoadClassType), which provides the number of levels in the road-class hierarchy. This hierarchy ranks the roads according to their relative size or importance in the route.

2.3.3 Data type of a single instruction
In this section, the data type representing a single route direction is described, including an description of the simple and complex types of the used attributes and elements.

14

2.3. DATA STRUCTURE OF THE NAVIGATION SERVICE AbstractManeuverType The complex type AbstractManeuverType (cf. Fig. 2.2) 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 0..1 junctionType +junctionName: String +id: ID

gml:PointType cf. GML-Specification
<<Abstract>> <<Abstract>> ManeuverPoint

AbstractManeuverType required optional
+numberExitsToPass: nonNegativeInteger

AbstractMeasureType
+value: decimal

required
+accuracy: decimal

optional

optional DistanceType
<<Abstract>> directionOfTurn

RouteSegmentType
actionType +TravelTime: Duration +name: string

Distance

optional

BoundingBox uom 0..1 <<Enumeration>> _NextSegment 0..1

RouteSegmentExtendedType

TurnDirectionType
+Straight +KeepLeft +KeepRight +SlightLeft +Left +SharpLeft +SlightRight +Right +SharpRight +UTurn

<<Enumeration>>

<<Enumeration>>

RouteActionType
+Turn +ProceedTo +Embark +Disembark +Stop +Advisory

DistanceUnitType
+KM +M +DM +MI +YD +FT

gml:EnvelopeType cf. GML-Specification

0..1

Figure 2.2: Data structure of an abstract route maneuver in OpenLS.

For this purpose an AbstractManeuverType contains the following elements and attributes: Elements: ManeuverPoint The 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 an element of the GML–speci?cation [2]. 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. Attributes: id Each instruction in OpenLS has a unique identi?er (id). It is of type ID. junctionName Encoded as a simple string, the name of the current intersection is provided by this optional attribute.

15

CHAPTER 2. OPENLS
? Turn ? ProceedTo ? Embark ? Disembark ? Stop ? Advisory

Figure 2.3: List of possible actions described in a route direction of OpenLS. junctionType The type of the current intersection is given by this optional attribute. It is of the simple type JunctionCategoryType (cf. Section 2.3.3). 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 speci?cation. actionType Each instruction describes an action stored in this attribute of the simple type RouteActionType (cf. Section 2.3.3 and Fig. 2.3). 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 di?erent value directionOfTurn should not be used. AbstractRouteSegment A route direction in OpenLS always includes data about the next route segment the traveller needs to follow after passing the current decision point. This data is provided by elements of the type AbstractRouteSegment. They contain elements that specify the distance of 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 a decision point, OpenLS introduces several categories of describing the action. Hence, every route direction provides an attribute of the simple type RouteActionType. It enumerates the possible action categories. The values an attribute of this type can take and their meaning according to the documentation of OpenLS are:

16

2.3. DATA STRUCTURE OF THE NAVIGATION SERVICE ? Turn: Instructing the traveller to enter the next route segment ? ProceedTo: Directing a way?nder to enter a segment without specifying the action (e.g., used for the ?rst route direction) ? Embark: Instructing a way?nder to enter, for example, public transport ? Disembark: Directing a way?nder to get o?, for example, public transport ? Stop: Notifying a way?nder that she arrived at a stopping point ? Advisory: Used for instructing a way?nder to keep on following 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 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 as it is not restricted in the schema itself. JunctionCategoryType Each route direction in OpenLS is categorized according to the type of intersection at which the described action has to be performed. Eight categories of intersections are introduced (cf. Fig. 2.4). Each route maneuver contains an attribute of the simple type JunctionCategoryType, which enumerates the possible types of intersections.
? Intersection ? Roundabout ? EnclosedTra?cArea ? EntranceRamp ? ExitRamp ? ChangeOver ? BoardingRamp ? None

Figure 2.4: Categories of intersections in OpenLS. These categories distinguish between general intersections, roundabouts, and enclosed tra?c areas, which are described in the speci?cation as “an area in which unstructured tra?c movements are allowed” [1, p. 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 a travel advisory) the attribute can take the value none.

17

CHAPTER 2. OPENLS TurnDirectionType If a route instruction describes a turn the traveller has to perform the attribute directionOfTurn of the type TurnDirectionType is used, which speci?es the directional change at the decision point (cf. Fig. 2.5). It is not to be used if the attribute actionType takes another value than Turn (cf. Section 2.3.3).
? Straight ? KeepLeft ? KeepRight ? SlightLeft ? Left ? SharpLeft ? SlightRight ? Right ? SharpRight ? UTurn

Figure 2.5: Possible directional changes in OpenLS. The simple type TurnDirectionType de?nes an enumeration of all possible descriptions of directional change. The directions are encoded as verbal expressions. It covers an eight-sector direction model (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 actual angular change for each of these direction changes. Therefore, it is not possible to decide on which concrete direction model the speci?cation is based.

2.3.4 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 de?ned inheriting the characteristics of an AbstractManeuverType. The OpenLS speci?cation o?ers one non–abstract complex type, which is derived from AbstractManeuverType (cf. Fig. 2.3.3). 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 generate a much more elaborate instruction. Every advisory is categorised by its attribute of the simple type AdvisoryCategoryType. The actual category depends on what the advisory is informing about. The possible categories are: ? StartLocation: The start point of the route

18

<<Abstract>>

AbstractManeuverType
+id: ID

Figure 2.6: Data structure of an extended route maneuver in OpenLS.

required
+junctionName: String

optional
+numberExitsToPass: nonNegativeInteger

optional
+ManeuverPoint: gml:PointType +_NextSegment: RouteSegmentExtendedType

minOccurs=0
+actionType: RouteActionType

2.3. DATA STRUCTURE OF THE NAVIGATION SERVICE

required
+directionOfTurn: TurnDirectionType

optional
+junctionType: JunctionCategoryType

optional

ManeuverType
+towardsSignText: string

optional
+nextManeuverFollowsImmediately: boolean

optional

AdvisoryType
Geometry Place Advisory 0..1

+associatedName: string

optional
0..1 placeType

0..1 <<Abstract>>

<<Abstract>>

AbstractManeuverGeometryType

NamedPlaceType
+name: string

19

AbstractMeasureType
+value: decimal +accuracy: decimal <<Abstract>>

type

sideOfRoad

AbstractLinkType

0..1 <<Enumeration>>

type

LinkType
+id: ID

1..*

NamedPlaceClassification
+CountrySubdivision +CountrySecondarySubdivision +Municipality +MunicipalitySubdivision

AngleType
+uom: string = DecimalDegrees
0..1

InterLinkAngle

optional
+accessible: boolean

<<Enumeration>>

SideOfRoadType
+Left +Right +Both

optional

PositionOnRoundabout

optional
+oneWay: boolean

DistanceType

0..1 Length

optional
+isManeuverEntryLink: boolean

optional
+isManeuverExitLink: boolean

<<simpleType>>
uom

positiveInteger

optional
_Link

<<Enumeration>>

+isRouteLink: boolean

AdvisoryCategoryType
+StartLocation +EndLocation +ViaLocation +EnterPlace +ExitPlace +BypassCity +StreetNameChange +Tollbooth +Landmark +Crossroad +HighwaysMerge +RampMerge +RoadsMerge

optional
0..1

<<Enumeration>>

<<simpleType>>

RoadClass 0..1

+previousLinkID: IDREF

DistanceUnitType
+KM +M +DM +MI +YD +FT

RoadClassType

optional

ExitRampType ChangeoverType

EntranceRampType BoardingRampType

ConnectedLinksType

IntersectionType

RoundaboutType

EnclosedTrafficAreaType

CHAPTER 2. OPENLS ? EndLocation: The end point of the route ? ViaLocation: A special location the route leads through ? EnterPlace: Informs a way?nder that she enters a named place (e.g., a country, state, or city) ? ExitPlace: Leaving a named place ? BypassCity: Turning on a branch to bypass a city ? StreetNameChange: At this location , a change of the street name occurs ? Tollbooth: Passing a tollbooth ? Landmark: Passing or turning at a landmark ? Crossroad: Passing or turning at a crossroad ? HighwaysMerge: The highway a way?nder is currently on merges with another highway ? RampMerge: A ramp merges with a current road ? RoadsMerge: The road a way?nder is currently on merges with another road Furthermore, an advisory is associated with a name (associatedName) and contains an optional attribute of the type NamedPlaceClassi?cation. This provides the level in a hierarchy de?ned by comprising the di?erent types: CountrySubDivision, 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 either one side of the road or both. namedPlaceType Similar to an advisory the extended route instructions have an attribute of the type NamedPlaceClassi?cation, which stores the level of the hierarchy explained in the previous section. 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 by 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 states the angle of the outgoing branch relative to the branch

20

2.3. DATA STRUCTURE OF THE NAVIGATION SERVICE 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). Apart from the actual geometric information, the type of the road is 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 provided by this type regards the role of the link in the current route. A link can be an entrance link (boolean attribute isManeuverEntranceLink), an exit link (boolean attribute isManeuverExitLink), or a route link (boolean attribute isRouteLink). The exact meaning of these links is not speci?ed [2, p. 38]. Again, the use of these attributes is optional. Finally, LinkType contains some internal information. 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 heading for is given. nextManeuverFollowsImmediately The meaning of this boolean attribute is not speci?ed in the OpenLS speci?cation. It is probably used to specify situations where the next action to take follows very shortly after the current action, i.e. a way?nder has only very short time to prepare for the next action. Its usage is optional.

21

3 Cognitive OpenLS
The OpenLS standard as de?ned by the OGC does not support cognitively ergonomic route directions. In this chapter, we propose an extension that integrates precise direction concepts, landmarks and spatial chunking of route directions in the OpenLS speci?cation. 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 and their implementation are described in detail in this chapter. The XML speci?cation of our extension is listed in Chapter 5.

3.1 Approach
Since the current version of the OpenLS speci?cation does not support all necessary features for generating cognitively ergonomic route directions, the standard, or more precisely the underlying data model, has to be extended. To this end it is su?cient to adapt some types in the data structure of the navigation service. The extension replaces the complex types AbstractRouteManeuverList, AbstractManeuverType and all related types. The proposed data types are integrated in the data structure in the same way the o?cial extension of the AbstractManeuverType, the ManeuverType are implemented. All new types are derived from the original type. In the following, the aspects regarded in the extension are explained. It is distinguished between aspects of human ergonomic route directions and additional aspects which are integrated for technical reasons. Furthermore, the approach for the technical realization is brie?y discussed.

3.1.1 Cognitively ergonomic route directions
The main concern of the proposed extension of the OpenLS speci?cation is to enable the automatic generation of cognitively ergonomic route directions based on the OpenLS data model. Thus, all aspects discussed in Chapter 1 are regarded: ? Direction model: The direction model the encoding of the provided turn direction is based on is adapted from the direction model presented by [9] in combination with naming the structure of the intersection. This is further detailed in Section 3.4.1. ? Structure of intersections: Including references to the structure of an intersection is explained in Section 3.4.2.

23

CHAPTER 3. COGNITIVE OPENLS ? Landmarks: Landmarks play an important role in giving route directions. We integrate an elaborated model for their description in OpenLS (cf. Section 3.5). ? Chunking: The extended version of OpenLS o?ers the possibility of spatialchunking. The implementation of the combination of Klippel’s [12] and Dale’s [3] approach is described in Section 3.6.

3.1.2 Additional Features
Besides of the aspects of cognitively ergonomic route directions some additional features are integrated in the OpenLS speci?cation. They 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 speci?cation (cf. Section 3.2.1). ? End point: Similar to the start point the end point of route requires special attributes. A special complex type providing the necessary attributes is introduced (cf. Section 3.2.2).

3.1.3 Technical realisation
Data about a single instruction in a Navigation Response is signi?cantly increased in the new version of the OpenLS speci?cation. 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 one of the two versions cannot deal with the abstract data types of the other.

3.2 Extending RouteManeuverList
In a list of single route directions, the start point and the end point of the route play a special role. Instructions on the start point helps the way?nder to orientate and to commence the route in the correct direction. The end point unambiguously identi?es the actual destination. Since start and end point have to be treated separately, they should also be indicated explicitly in the list of the route maneuver. Thus, a complex type XRouteManeuverListType is derived from AbstractRouteManeuverList, which adds two elements containing information about the start and the end point of a 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 OpenL?S Navigation Service. Additionally, like in RouteManeuverList the attribute maximumRoadClass is used. An UML–diagram of the relationship between the single types, their attributes and elements is shown in ?gure 3.1. The exact structure of a start and an end point is explained in the following two sections.

24

3.2. EXTENDING ROUTEMANEUVERLIST

<<Abstract>> <<Abstract>> _Manuever 1..*

AbstractRouteManeuverList

AbstractManeuverType cf. figure xy

<<simpleType>>

positiveInteger

XRouteManeuverListType

<<simpleType>>

0..1 maximumRoadClass EndManeuver

StartingManeuver

RoadClassType optional XEndManeuverType
+Address: AddressType +SideOfRoad: SidOfRoadType

XStartingManeuverType
+Address: AddressType +SideOfRoad: SidOfRoadType +position: gml:PointType +RoadDiretion: RoadDirectionType

optional
+Landmark: StratLMType

optional
+position: gml:PointType +Landmark: EndLMType

optional
+Orientation: gml:CompassPointEnumeration

optional

optional

Figure 3.1: Diagram of the extended data structure of a route maneuver list.

3.2.1 XStartingManeuverType
Orientating the way?nder at the beginning of the route is a crucial part in giving route directions. It has to be assured that the way?nder follows the ?rst route segment 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 ?rst orientation (cf. Fig. 3.2.1). 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 complex type AddressType of the OpenLS speci?cation is used. It can contain either an unstructured free form 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, a way?nder has to follow the ?rst segment of the route. At the start point, facing the road the way?nder can either turn left or right or he 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 The complex type XStartingManeuver additionally o?ers an attribute providing the cardinal direction in which the way?nder has to go. For this purpose the simple type from the GML speci?cation CompassPointEnumeration is used. It splits the possible directions into 16 homogeneous sectors. Each sector is represented by a cardinal direction (e.g., south).

25

CHAPTER 3. COGNITIVE OPENLS

First route segment Line of sight Traveller

Figure 3.2: This ?gure depicts the assumed position of the way?nder at the start of a route. To follow the route the way?nder has to turn right.

Landmark The third possibility of orientating the way?nder 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 3.5.2). id A start maneuver has an ID that identi?es it unambiguously.

3.2.2 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 way?nder to identify the destination of her route. Therefore, elements of this type provide the following information (cf. Fig. 3.2.1). Position The exact geographic position encoded as an gml:PointType of the end 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 o?ers 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 may 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.

????????????????? ? ? ? ? ? ? ? ? ???????????????????? ???????????????????? ???????????????????? ?????????????????? ??????????????????? ?????????????????? ????????????

Start location

26

<<Abstract>>

AbstractManeuverType

Figure 3.3: Data structure of a start maneuver and an end maneuver.

+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

3.2. EXTENDING ROUTEMANEUVERLIST

XStartingManeuver
+id: ID

required

XEndManeuver

27

<<Enumeration>>

0..1 RoadDirection

Address

RoadDirectionType
+Left +Right +Straight SideOfRoad

AddressType cf. OpenLS-Specification

Address

Landmark

EndLMType
+PictureData: string (base64)

choice
+PictureURL: string

choice
<<Enumeration>> SideOfRoad +SpatialRelation: EndLMRelation

StartLMType
+PictureData: string (base64)

Landmark

SideOfRoadType
+Left +Right +Both

optional
+SideOfRoad: SideOfRoadType +PointPosition: gml:PointType

choice
+PictureURL: string

Choice
+LinePosition: gml:LineType

choice
+SpatialRelation: StartLMRelation

Choice
+AreaPosition: gml:PolygonType Position

optional
+SideOfRoad: SideOfRoadType +PointPosition: gml:PointType

gml:PointType cf. GML-specification

Position

Choice
+id: ID

Choice
+LinePosition: gml:LineType

required

Choice
+AreaPosition: gml:PolygonType Orientation

Choice

gml:CompassPointEnumeration cf. GML-specification

PreviousSegment

XRouteSegmentExtendedType
+Landmark: NonDPPLMType

CHAPTER 3. COGNITIVE OPENLS 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. id A start maneuver has an ID that identi?es it unambiguously.

3.3 XManeuverType
Route directions based on the complex type AbstractManeuverType do not support cognitively ergonomic route directions. Also the type ManeuverType derived from AbstractManeuverType does not o?er the necessary features to encode all information for generating the aspects of cognitively ergonomic route instructions. Hence, the 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. 3.3.1).

3.3.1 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 attribute is: id This attribute encodes an identi?cation number in order to identify the direction unambiguously as an attribute of the simple type ID. The new attributes are: previousSegment In our extension 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. nextStreet This attribute contains the name of the street the way?nder is turning in when she performs the described maneuver. The 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 these should not be used in Cognitive OpenLS. JunctionCategory Since the element JunctionType of the complex type AbstractManeuverType does not o?er 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 3.4.3.

28

3.3. XMANEUVERTYPE
<<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>>

JunctionCategory

Landmark

0..*

<<Abstract>>

0..*

AbstractJunctionType
+RouteBranch: gml:AngleType +NoRouteBranch: gml:AngleType

NonDPPLMType
+SpatialRelation: SpatialRelationNonDPType +PointPosition: gml:PointType

maxOccur = unbounded

Choice
+LinePosition: gml:LineStringType

Choice
+AreaPosition: gml:PolygonType

Choice

Figure 3.4: The extended data structure of a route maneuver.

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. 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 type Abstract1ElementLMType provides all required information about a landmark with a point-like function. In principle, the number of landmarks associated with a decision point is unbounded. The attributes and elements of AbstractPointLikeLMType and its sub–types are described in Section 3.5.

3.3.2 Replacing NextSegment by CurrentSegment
In an elementary route direction always (apart from the start point) a decision point and the previous route segment are combined. 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 an element based on the complex type AbstractManeuverType of the original version of the Navigation Service, a decision point is combined with the

29

CHAPTER 3. COGNITIVE OPENLS 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. 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. A segment can be related to 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 the new street name encoded as string and the position of the change as gml:PointType. Streetname This attribute stores the name of the street to which the segment belongs. In contrast to the name provided by RouteSegmentExtendedType, this attribute is required.

3.4 Making route directions more precise
According to the aspects of cognitively ergonomic route directions our OpenLS extension introduces data types, which describe the spatial situation at a decision point as exactly as necessary and combines this with a direction concept specifying the turn direction.

3.4.1 Direction model
In the current version of the Navigation Service, a direction is described by a verbal expression. OpenLS o?ers a collection of ten verbal expressions in a simple data type. How the underlying direction model structures the space is not further explained. Similar to the original verbal expressions, the proposed extension of the speci?cation o?ers simple types for di?erent kinds of intersections providing an appropriate direction concept and its respective direction. Relating structure of the intersection and appropriate directions constrains insensible combinations. The directions for each type of intersection are encoded as enumerations of verbal expressions. However, these verbal expressions are not necessarily to be used in the route directions ?nally presented to a user. The verbal expressions are only used in order to make the encoding of the data more 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

30

3.4. MAKING ROUTE DIRECTIONS MORE PRECISE
? T–Intersection ? Fork intersection ? Standard intersection ? Intersection with competing branches ? Small roundabout ? Large roundabout

Figure 3.5: List of possible types of intersections. right.The de?nition 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 speci?ed which directions should be represented by straight and subject to ongoing research.

3.4.2 Naming the structure
Describing the spatial situation at an intersection helps the way?nder to orientate herelf 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. 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 classi?ed by standard types. The o?ered types of intersections are listed in ?gure 3.5.

3.4.3 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 minimizes the possibility of creating unambiguous instructions. Therefore, several new types for supporting this purpose are introduced (cf. Fig. 3.4.3). AbstractJunctionType The proposed extension classi?es each intersection into a category. Each category is represented by a complex type derived from 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.

31

CHAPTER 3. COGNITIVE OPENLS Encoding the spatial structure For each intersection its spatial structure has to be provided. This allows giving the way?nder 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 information on 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 on which the way?nder leaves the intersection must be stored in a separate element, since it has to be possible to distinguish it from the other branches due to its special role. 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>>

CompetingBranchesType
+numberExitsToPass: positiveInteger

SmallRoundaboutType

noCompetingBranchesType

LargeRoundaboutType
+numberExitsToPass: positiveInteger

TurnDirection

TIntersectionType

StandardIntersectionType
TurnDirection

<<Enumeration>>

TurnDirectionTypeSR
+Right +Left +Straight

ForkIntersectionType
TurnDirection TurnDirection

TurnDirection

<<Enumeration>>

TurnDirectionTypeC
+Right +Left <<Enumeration>> <<Enumeration>>

TurnDirectionTypeSR
+Right +Left +Straight

TurnDirectionTypeSR
+Right +Left

Figure 3.6: Data structure of the di?erent types of intersections.

AbstractNoCompetingBranchesType Junctions of the type AbstractNoCompetingBranchesType can be classi?ed in one of the categories T–intersection, Fork–intersection and standard intersection. For these classes of intersections it is su?cient 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–intersections are intersections where the road on which the way?nder arrives ends at the intersection. If the way?nder approaches the same intersection on a di?erent branch, it is not classi?ed as a T–intersection but as a standard intersection. The only attribute of this type contains the

32

3.4. MAKING ROUTE DIRECTIONS MORE PRECISE 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 sets whether it is categorised as fork intersection or not. The way?nder has to arrive on the branch that splits into the two other branches. Also similar to the T–intersection, it provides only one attribute of the simple type TFTurnDirectionType. StandardIntersectionType All other intersections that have no branch competing with the outgoing branch belong to the category standard intersection. The complex type of 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 a left and a right part. Two branches of an intersection compete with each other, if they are both either in the right or the left part. A branch going straight cannot compete with another branch. 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 coarse turn direction (left or right) with an ordering concept: the competing branches are counted and the appropriate number is chosen for the branch to take. 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 parts of the space of turn directions. SmallRoundAboutType Two di?erent classes 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 comprehensible without problems. 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 previously. 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 way?nder must pass in the roundabout. The only attribute that an element the complex type

33

CHAPTER 3. COGNITIVE OPENLS LargeRoundaboutType has is a simple integer value, which gives the number of exits to pass at the roundabout.

3.5 Integration of landmarks in OpenLS
Landmarks play an important role in route directions. They can have di?erent purposes and functions, for example, they can be used for identifying segments and decision points, they can help a way?nder to orientate or they can specify a required action. According to their di?erent functions, we set up a taxonomy for the classi?cation of landmarks (cf. [7]). This taxonomy is used as a basis for the abstract data types representing landmarks in the proposed extension of the OpenLS speci?cation. The usage and function of these newly introduced types depends on the context of other types, which are contained as elements. This is discussed in the following in the presentation of the di?erent complex landmark types.

3.5.1 AbstractLandmarkType
All complex types representing a particular type of landmark are derived from the abstract type AbstractLandmarkType. This type contains all elements and attributes common to all landmarks. The elements and attributes of AbstractLandmarkType are the name (Name) and a description (description) of the landmark. The attribute Name should contain the o?cial name of the landmark. The description should provide all information that is necessary to enable the way?nder 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 3.5.5.

3.5.2 Landmarks for orientation at Start and End Point
The types StartingPointLMType and EndPointLMType provide all information about the landmarks used for orientating the way?nder at start and end of a route. StartingPointLMType By choosing the information that is provided by an element representing a start point the situation of a way?nder has to be regarded. It is to assume that the way?nder is not familiar with the environment. Therefore, she do not know which direction she has to head to in order to follow the route. She also does not know where the landmark is located and how it looks like. Thus, the complex type StartingPointLMType is introduced (cf. Fig. 3.5.2). Additionally to the attribute Name and the element Description, which are already contained by

34

3.5. INTEGRATION OF LANDMARKS IN OPENLS 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 way?nder 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 way?nder’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. SpatialRelation In this optional attribute the information whether a way?nder has to follow the ?rst segment towards or away from the landmark is stored. EndPointLMType In contrast to the start of a route, the way?nder is already correctly oriented on the last route segment. The task of the last instruction is to support the way?nder in identifying her ?nal destination. The end point of a route is in most cases a street address, which is usually identi?ed by its house number. Since this number is quite often not visible or not easy to spot for the way?nder, it is helpful to describe the position of the destination of the route in relation to a much more salient landmark. Therefore, the complex type EndPointLMType is introduced (cf. Fig 3.5.2). It provides, additionally to the name and a description of the landmark, the following elements in order to ful?ll this task: 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. SpatialRelation The attribute SpatialRelation stores 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 de?ned by the simple type EndLMRelationType. According to this a landmark used to identify the destination of a route can be located next to the destination (left or right) or opposite to it. SideOfRoad Since the way?nder is following a road, the landmark can be located either on the right side of the road, the left side or on both. This information is stored in this optional attribute.

35

CHAPTER 3. COGNITIVE OPENLS
<<Abstract>> LMClass <<Abstract>>

AbstractLandmarkType
+Name: String

AbstractDescriptionLMType

<<Abstract>>

<<Abstract>>

StartPointLMType

EndPointLMType

AbstractNElementLMType

Abstract1ElementLMType

AreaLMNType
<<Abstract>>

LinearLikeLMType
PolygonPosition

SideOfRoad

<<Enumeration>>

SideOfRoad

SideOfRoadType gml:PolygonType cf. GML-specification
+Left +Right +Both

LinePosition

NotIdentifyingLLMType

Landmark

<<Abstract>>

gml:LineType cf. GML-specification

LinePosition

Abstract1EDPLMType
AreaPosition

gml:PolygonType cf. GML-specification

AreaPosition

IdentifyingLLMType
PointPosition SpatialRelation <<Enumeration>>

gml:PointType cf. GML-specification

PointPosition

SpatialRelationLinearIdentType
LinePosition

SpatialRelation <<Enumeration>>

gml:LineTypeType cf. GML-specification

+along +after

SpatialRelation

<<Enumeration>>

StartLMRelation

EndLMRelation

Orientation

gml:CompassPointEnumeration cf. GML-specification

Figure 3.7: Data structure representing n–Elements landmarks, StartingPointLMType and EndPointLMType.

3.5.3 AbstractNElementLMType
Landmarks related to more than one route element are represented by the abstract class AbstractNElementLMType (cf. Fig 3.5.2). Two child–classes representing the two required sub–categories are introduced. AbstractLineLMType stores information on landmarks conceptualised as linear and AreaLMNType those conceptualised as area–like. AreaLMNType Area–like landmarks identifying a chunk of route elements are represented by the complex type AreaLMNType. Since there are no types derived from this type, it is not abstract. Landmarks of this type have one additional element: PolygonPosition For giving the position of the landmark a polygon is provided in this element. The polygon is encoded according to the GML speci?cation 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. AbstractLinearLikeLMType is introduced, which covers with its attributes and elements the characteristics common to all types of landmarks with a linear function.

36

3.5. INTEGRATION OF LANDMARKS IN OPENLS 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:LineStringType. 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 kind of landmarks represented by IdentifyingLLType do not require reference to an additional landmark to identify this point. It is su?cient 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. NotIdentifyingLLType Linear objects along the route, which are able to describe the course of the route due to their geometry but are not su?cient 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 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 described by an additional landmark with a pointlike function. Therefore, the element Landmark provides the required additional information encoded as the complex type AbstractPointLMType. This type is described later in this chapter.

3.5.4 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 abstract complex type Abstract1ElementLMType represents with its two child–classes these two categories (cf. Fig. 3.5.4). Abstract1EDPLMType The abstract complex type Abstract1EDPLLMType represents the supertype for all landmarks identifying only one decision point. Using this type allows for introducing in the type XManeuverType only one element (of an unbounded occurance) 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.

37

CHAPTER 3. COGNITIVE OPENLS AreaLM1Type Landmarks with an area–like function are represented by the complex type AreaLM1Type. It is derived from the type Abstract1EDPLLMType. The elements neeeded to identify a single decision point located within an area–like landmark requires the following attributes: PolygonPosition For giving the position of the landmark a polygon is provided. The polygon is encoded according to the GML speci?cation as a gml:PolygonType. The spatial relation of such a landmark to a decision point is always in. Thus, it is implicitly encoded in the complex type AreaLM1Type. StructureLMType The spatial con?guration of an intersection can be salient enough to function as a point–like landmark. The complex type StructureLMType is introduced providing the information necessary for the identi?cation of an intersection functioning as a 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 the 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 Streets identi?ed by their name can function as point–like landmarks. They are represented by the complex type StreetNameLMType, which provides the required information the way?nder needs in order to identify the particular street at the decision point. Since the name of the landmark is already contained in the supertype 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 way?nder 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.

38

<<Abstract>>

LMClass

<<Abstract>>

AbstractLandmarkType
+Name: String

AbstractDescriptionLMType

Figure 3.8: Data structure representing 1–Element landmarks.

<<Abstract>>

Abstract1ElementLMType

3.5. INTEGRATION OF LANDMARKS IN OPENLS

<<Abstract>>

Abstract1EDPPLMType

NonDPPLMType

AreaLM1Type

<<Abstract>>

<<Enumeration>>

SpatialRelation

39

AbstractDPPLLMType

SpatialRelationNonDPType
+pass +cross +through

PolygonPosition

gml:PolygonType cf. GML-specification

StructureLMType

GSOLMType

Intersection <<Abstract>>

PointPosition

gml:PointType cf. GML-specification gml:LineStringType cf. GML-specification gml:PolygonType cf. GML-specification
<<Enumeration>>

PointPosition

AbstractJunctionType

LinePosition

LinePosition

PolygonPosition

PolygonPosition

StreetNameLMType
SpatialRelation

SpatialRelationGSOType gml:AngleType cf. GML-specification
PositionAtIntersection +at +after +before

CHAPTER 3. COGNITIVE OPENLS PointPosition, LinePosition, AreaPosition A GSO can have an area–like, linear or point–like geometry. Accordingly, there is a choice between di?erent ways to encode the geographic location. The position is encoded either as gml:PointType, as gml:LineStringType, or as gml:PolygonType. SpatialRelation This attribute gives the spatial relation of the described object to the route segment. It is of the simple type SpatialRelationGSOType, which lists all possible spatial relations identi?ed by a verbal label (cf. ?gure 3.9).
? before ? after ? at

Figure 3.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 di?erent geometries, there is a choice between di?erent 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 the landmark, the relation can be pass, cross or through.

3.5.5 Description of Landmarks
For using landmarks properly in route directions, they need to be described in order to be identi?able. A way?nder 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 ?nally generated instruction, the information for describing a landmark has to be encoded independent from constraints imposed, for example, by concrete verbal description. Presently, this problem has not yet been su?ciently solved. Here, only a short sketch of a possible solution is outlined to de?ne a non–abstract type for generating example documents based on the proposed extension.

40

3.6. CHUNKING ROUTE DIRECTIONS PictureData In order to enable the way?nder 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 de?ned in the IETF (Internet Engineering Task Force) standard for Multipurpose Internet Mail Extensions [6]. This scheme for encoding binary data in a string is also used in other parts of the OpenLS speci?cation. 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.

3.6 Chunking Route Directions
Spatial chunking allows reducing the number of route directions, and by building up a hierarchy subsumes instructions to focus on the 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 presented in [12] and [3], several changes in the design of the data structure described in XLS have to be made. The possibility of subsuming a sequence of directions in one single instruction has to be introduced to allow for spatial chunking. To build up a hierarchy it is also necessary to o?er 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. This way they know that there is more detailed information accessible if the summarised direction is not su?cient for them. Such an instruction has to contain all the information about each subsumed decision point, so it is not necessary to contact the server again for requesting more speci?c instructions. For the internal data structure, it is helpful if higher order route segments can be used in the same way as any other elementary instruction. This allows the combination of chunks of di?erent levels in one segment. For example, a list of instructions may consist 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

41

CHAPTER 3. COGNITIVE OPENLS each possible chunking type (e.g., based on the di?erent 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.
<<Abstract>> 2..*

AbstractManeuverType
+id: ID

required
+junctionName: String

optional
+numberExitsToPass: nonNegativeInteger

optional
+ManeuverPoint: gml:PointType +_NextSegment: RouteSegmentExtendedType

minOccurs=0
+actionType: RouteActionType ChunkedManeuver

required
+directionOfTurn: TurnDirectionType

optional
+junctionType: JunctionCategoryType

optional

ChunkType
+NumberOfPassedDP: positiveInteger +Streetname: string

optional

ChunkingElement

ChunkingElement

<<Abstract>>

ChunkingElement

AbstractChunkingElementType

RoadHierarchyChunkType
+LevelName: string

NElementMChunkingType

<<Abstract>>

PointLMChunkingType
ChunkingLM

StructureChunkType
+TIntersection: TIntersectionType

Choice
+ForkIntersection: ForkIntersectionType

AbstractNElementLMType
ChunkingLM

Choice
+SRoundabout: SmallRoundaboutType

Choice
+LRoundabout: LRoundaboutType

Choice Abstract1EDPPLMType

NumericalChunkingStraightType

NumericalChunkingTurnType

TurnDirectionAtLastDP

ChunkDirection

<<Enumeration>>

TurnDirectionTypeChunk
+Right +Left

Figure 3.10: Data Structure supporting Chunking.

3.6.1 ChunkType
To enable chunking, the complex type 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.

42

3.6. CHUNKING ROUTE 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 these directions, an optional street name and the element ChunkingElement. NumberOfPassedDP This attribute states for how many decision points the way?nder has to perform the described action. It is essential for numerical chunking where this is the basic information. But it can also be used for other types of chunking as additional information for supporting the identi?cation 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 an object of the type ChunkType. This allows building 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 this is requested by the user. 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 element ChunkingElement, 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 AbstractChunkElement. 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 this element is optional to avoid further redundancy. These elements de?ne the type of chunking, which is used to create this subsuming instruction. For each single type of chunking, one type derived

43

CHAPTER 3. COGNITIVE OPENLS from AbstractChunkElement 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.

3.6.2 AbstractChunkElement
For each possibility to indicate the last decision point of a sequence of chunked route directions, an element of a di?erent type is used. Chunking based on the name of the street 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 di?ers depending, for example, on the country (the administrative road hierarchy can vary in di?erent countries) and the actual type of hierarchy (e.g., an o?cial 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 o?cial 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 necessary information 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 category of directional change has to be identical 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 points without directional change.

44

PointLMChunkingType For using a point–landmark as chunking element and, thus, 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. Like the PointLMChunkingType it contains a landmark, but of the type AbstractNElementLMType. If the landmark is not su?cient 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 numerical chunking.

CHAPTER 3. COGNITIVE OPENLS

46

4 Examples of Cognitive OpenLS
In this chapter we provide some handcrafted examples on how to specify route directions using Cognitive OpenLS. All examples are based on real situations, but the used data is not based on an exisiting data set. For creating the examples, a route was calculated using the navigation service www.uk.map24.com and turned manually into an encoding in Cognitive OpenLS. Due to this method of generating the required data, there is no geospatial data available and thus, no exact angular information; all elements storing geographic coordinates are set on default values. Only the ?rst example covers the description of a complete route. All others focus on a certain aspect and, thus, contain only selected elements of the XLS-code. For each example we provide possible verbal externalizations that, again, are only used to illustrate the data-structure. They are not generated by any automatic system, nor are they meant to be the only possible solution. All pictures used in this chapter are based on maps generated with www.uk.map24.com in March 2006.

4.1 Example 1: A complete route
The ?rst example is the only one that covers a complete route from start point to end point. The route starts at Ronzelenstrasse 18, 28359 Bremen and ends at the Ortsamt Horn-Lehe (Berckstrasse 10, 28359 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 ?le starts with a header de?ning the name space and the other included XML-schemas. The extended version of XLS needs to include the schema-?le ADT NavXtension.xsd.
1 2
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF?8” ?> <x l s : X M a n e u v e r L i s t x m l n s : x l s=” h t t p : //www. o p e n g i s . n e t / x l s ” x m l n s : s c h=” h t t p : //www. a s c c . n e t / xml/ schematron ” x m l n s : g m l=” h t t p : //www. o p e n g i s . n e t / gml ” x m l n s : x l i n k=” h t t p : //www. w3 . o r g /1999/ x l i n k ” x m l n s : x s i=” h t t p : // www. w3 . o r g /2001/ XMLSchema?instance ” x s i : s c h e m a L o c a t i o n=” h t t p : //www. opengis . net / x l s D:\ xml\ o l s 1 1 \05?016\ ADT NavXtension . xsd ”>

3

The description of the route starts with a chunk subsuming the two decision points of the route. The start 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.

47

CHAPTER 4. EXAMPLES OF COGNITIVE OPENLS

Riensberger Str.

Leher Heerstr.

Berckstrasse 10
Berckstr.

Horner Kirche

Figure 4.1: Map of the route in example 1 from Ronzelenstrasse 18, 28359 Bremen to Berckstrasse 10, 28359 Bremen. Based on map from www.uk.map24.com from March 2006.

??? ¤ ¤? ¤? ¤ ?? ¤?¤????¤???¤ ??? ?¤?????? ??????¤????? ??? ?¤??¤??¤??¤ ?? ????? ??? ?? ?? ????

LESTRA
Horner Heerstr.

Ronzelenstrasse 18
Ronzelenstr.

48

4.1. EXAMPLE 1: A COMPLETE ROUTE
4 5 6 7 8
<xls:ChunkManeuver i d=” chunk1 ” a c t i o n T y p e=” A d v i s o r y ” NumberOfPassedDP=” 2 ”> <x l s : M a n e u v e r P o i n t> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : M a n e u v e r P o i n t>

The ?rst of the chunked maneuvers describes the action a way?nder has to perform at a T–intersection. This intersection is also used as a structural landmark; therefore the information about the intersection is encoded twice.
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
<xls:ChunkedManeuver x s i : t y p e=” xls:XManeuverType ” a c t i o n T y p e=”Turn ” i d=” dp1 ” d i r e c t i o n O f T u r n=” Right ” j u n c t i o n T y p e =” I n t e r s e c t i o n ” > <x l s : M a n e u v e r P o i n t> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : M a n e u v e r P o i n t> <x l s : J u n c t i o n C a t e g o r y x s i : t y p e=” x l s : T I n t e r s e c t i o n T y p e ” T u r n D i r e c t i o n=” r i g h t ”> <x l s : R o u t e B r a n c h S t r e e t n a m e=” Horner H e e r s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>90</ x l s : A n g l e> </ x l s : R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” Horner H e e r s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>270</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> </ x l s : J u n c t i o n C a t e g o r y > <x l s : L a n d m a r k x s i : t y p e=” x l s : S t r u c t u r e L M T y p e ”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i pt i o nE x a mp le T y p e”></ x l s : D e s c r i p t i o n> < x l s : I n t e r s e c t i o n x s i : t y p e=” x l s : T I n t e r s e c t i o n T y p e ” T u r n D i r e c t i o n= ” r i g h t ”> <x l s : R o u t e B r a n c h S t r e e t n a m e=” Horner H e e r s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>90</ x l s : A n g l e> </ x l s : R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” Horner H e e r s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>270</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> </ x l s : I n t e r s e c t i o n> </ x l s : L a n d m a r k> <x l s : P r e v i o u s S e g m e n t S t r e e t n a m e=” R o n z e l e n s t r a s s e ”> < x l s : D i s t a n c e v a l u e=” 10 ”></ x l s : D i s t a n c e> <x l s : T r a v e l T i m e>P1Y2M3DT10H30M12 . 3 S</ x l s : T r a v e l T i m e> <x l s : B o u n d i n g B o x> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : B o u n d i n g B o x> </ x l s : P r e v i o u s S e g m e n t> </ xls:ChunkedManeuver> <xls:ChunkedManeuver x s i : t y p e=” xls:XManeuverType ” a c t i o n T y p e=”Turn ” i d=” dp2 ” d i r e c t i o n O f T u r n=” Right ” j u n c t i o n T y p e =” I n t e r s e c t i o n ” > <x l s : M a n e u v e r P o i n t> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : M a n e u v e r P o i n t> <x l s : J u n c t i o n C a t e g o r y x s i : t y p e=” x l s : S t a n d a r d I n t e r s e c t i o n T y p e ” T u r n D i r e c t i o n=” r i g h t ”> <x l s : R o u t e B r a n c h S t r e e t n a m e=” B e r c k s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>90</ x l s : A n g l e> </ x l s : R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” R i e n s b e r g e r S t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>270</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” Leher H e e r s t r a s s e ”> <x l s : A n g l e uom=” ”>0</ x l s : A n g l e>

49

CHAPTER 4. EXAMPLES OF COGNITIVE OPENLS
55 56
</ x l s : N o R o u t e B r a n c h> </ x l s : J u n c t i o n C a t e g o r y >

The second of the chunked decision points is identi?ed by church, which functions as a GSO/point–landmark. The landmark is also integrated in the description of the required turn, since a way?nder has to perform a directional change after she passed the church.
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
<x l s : L a n d m a r k x s i : t y p e=”xls:GSOLMType ” Name=” Horner K i r c h e ” S p a t i a l R e l a t i o n=” a f t e r ” > < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i pt i o nE x a mp le T y p e”></ x l s : D e s c r i p t i o n> < x l s : P o i n t P o s i t i o n> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o i n t P o s i t i o n> </ x l s : L a n d m a r k> <x l s : P r e v i o u s S e g m e n t S t r e e t n a m e=” Horner H e e r s t r a s s e ”> < x l s : D i s t a n c e v a l u e=” 10 ”></ x l s : D i s t a n c e> <x l s : T r a v e l T i m e>P1Y2M3DT10H30M12 . 3 S</ x l s : T r a v e l T i m e> <x l s : B o u n d i n g B o x> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : B o u n d i n g B o x> </ x l s : P r e v i o u s S e g m e n t> </ 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 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.
76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

< x l s : L a s t I n t e r s e c t i o n x s i : t y p e=” x l s : S t a n d a r d I n t e r s e c t i o n T y p e ” T u r n D i r e c t i o n=” l e f t ”> <x l s : R o u t e B r a n c h S t r e e t n a m e=” Wilhelm?Kaisen?Bruecke”> <x l s : A n g l e uom=” d e g r e e ”>270</ x l s : A n g l e> </ x l s : R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” B a l g e b r u e c k s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>90</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” M a r t i n i s t r a s s e ”> <x l s : A n g l e uom=” ”>0</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> </ x l s : L a s t I n t e r s e c t i o n> <x l s : C h u n k i n g E l e m e n t x s i : t y p e=” xls:NumericalChun kin g Tu rnT yp e ” T u r n D i r e c t i o n=” r i g h t ”></ x l s : C h u n k i n g E l e m e n t> <x l s : C h u n k e d S e g m e n t s> <x l s : D i s t a n c e v a l u e=” 10 ”></ x l s : D i s t a n c e> <x l s : T r a v e l T i m e>P1Y2M3DT10H30M12 . 3 S</ x l s : T r a v e l T i m e> <x l s : B o u n d i n g B o x> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1</ g m l : p o s> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1</ g m l : p o s> </ x l s : B o u n d i n g B o x>

50

4.1. EXAMPLE 1: A COMPLETE ROUTE
100 101 102
</ x l s : C h u n k e d S e g m e n t s> </ xls:ChunkManeuver>

The start maneuver orients the way?nder at the beginning of the route. In this case the absolute direction (West), the direction according to the address and the ?rst route segment (right), and a landmark are provided. Since there is no better object available that could function as landmark just the next road the way?nder is heading towards is used.
76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
<x l s : S t a r t i n g M a n e u v e r i d=” S t a r t ” O r i e n t a t i o n=”W” R o a d D i r e c t i o n =” r i g h t ”> <x l s : A d d r e s s countryCode=”DE”> <x l s : f r e e F o r m A d d r e s s> R o n z e l e n s t r a s s e 1 0 , 28359 Bremen ( Horn?Lehe ) </ x l s : f r e e F o r m A d d r e s s> </ x l s : A d d r e s s> < x l s : P o s i t i o n> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o s i t i o n> <x l s : L a n d m a r k O r i e n t a t i o n=”W” S p a t i a l R e l a t i o n=” t o w a r d s ” Name=” Horner H e e r s t r a s s e ”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i p t io n Ex a m pl e Ty p e”></ x l s : D e s c r i p t i o n> <x l s : P o i n t P o s i t i o n> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o i n t P o s i t i o n> </ x l s : L a n d m a r k> </ x l s : S t a r t i n g M a n e u v e r>

For describing the destination of the route a point–landmark is given in the end maneuver. To inform the way?nder 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 way?nder’s current position. Furthermore, the relationship between destination and landmark is provided (opposite.
76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91
<xls:EndManeuver i d=” end ” SideOfRoad=” L e f t ”> <x l s : A d d r e s s countryCode=”DE”> <x l s : f r e e F o r m A d d r e s s>B e r c k s t r a s s e 1 0 , 28359 Bremen</ x l s : f r e e F o r m A d d r e s s> </ x l s : A d d r e s s> < x l s : P o s i t i o n> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o s i t i o n> <x l s : L a n d m a r k O r i e n t a t i o n=”N” Name=” L e s t r a ” SideOfRoad=” Right ” S p a t i a l R e l a t i o n=” o p p o s i t e ”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i p t io n Ex a m pl e Ty p e”></ x l s : D e s c r i p t i o n> <x l s : P o i n t P o s i t i o n> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o i n t P o s i t i o n> </ x l s : L a n d m a r k>

51

CHAPTER 4. EXAMPLES OF COGNITIVE OPENLS
92 93 94 95 96 97 98 99 100 101 102 103 104 105

<x l s : P r e v i o u s S e g m e n t S t r e e t n a m e=” B e r c k s t r a s s e ”> <x l s : D i s t a n c e v a l u e=” 12 ”></ x l s : D i s t a n c e> <x l s : T r a v e l T i m e>P1Y2M3DT10H30M12 . 3 S</ x l s : T r a v e l T i m e> <x l s : B o u n d i n g B o x> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1</ g m l : p o s> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1</ g m l : p o s> </ x l s : B o u n d i n g B o x> </ x l s : P r e v i o u s S e g m e n t> </ xls:EndManeuver>

</ x l s : X M a n e u v e r L i s t>

The example illustrates the basic usage of the data model and some more advanced features. This example demonstrates as many of the features as possible; some of them would not be used in the actual generated route directions. For example, the church describing the turn at the second decision point might not be mentioned since this turn is already described by the numerical chunk. Possible route directions based on this speci?cation are: 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.)

4.2 Example 2: Spatial chunking
The second example demonstrates chunking using a linear landmark and chunking using road hierarchy. The chunk employing 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 as a point-like landmark. 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 way?nder is still on the B75. She leaves it when she turns into Kornstrasse at the end of the chunk. This second part of the chunk combining the roads belonging to the B75 can also be subsumed using numerical chunking. The example starts with the ?rst chunk, which subsumes the two other chunks. Parts of the speci?cation that do not illustrate features not already contained in the ?rst example are replaced by [...] to shorten the listings. The ?rst chunked maneuver is already the other chunk, which subsumes also 9 maneuvers.
1 2
<xls:ChunkManeuver i d=”C1” a c t i o n T y p e=” A d v i s o r y ” NumberOfPassedDP=” 2 ”>

52

4.2. EXAMPLE 2: SPATIAL CHUNKING

Martinistr.

Wilhelm?Kaisen? Bruecke

Tiefer Berliner Str.

B75
Friedrich?Ebert?Str.

B75
Osterdeich

Kornstr.

Figure 4.2: Map of the route in example 2. It is based on a map provided by www.de.map24.com in March 2006.

53

CHAPTER 4. EXAMPLES OF COGNITIVE OPENLS
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
[...] <xls:ChunkedManeuver x s i : t y p e=” xls:ChunkType ” i d=”C2” a c t i o n T y p e=” A d v i s o r y ” NumberOfPassedDP=” 9 ”> [...] <xls:ChunkedManeuver x s i : t y p e=” xls:XManeuverType ” a c t i o n T y p e=”Turn ” i d=”M2” d i r e c t i o n O f T u r n=” S t r a i g h t ” j u n c t i o n T y p e =” I n t e r s e c t i o n ” > [...] </ xls:ChunkedManeuver> [...] <xls:ChunkedManeuver x s i : t y p e=” xls:XManeuverType ” a c t i o n T y p e=”Turn ” i d=”M10” d i r e c t i o n O f T u r n=” L e f t ” j u n c t i o n T y p e =” I n t e r s e c t i o n ”> [...] </ xls:ChunkedManeuver>

The river Weser is used for landmark chunking. Since this landmark is not su?cient to identify the end of the chunk, a point–landmark (a bridge) is used for this purpose. The second of the two chunks subsuming eight intersections uses again numerical chunking. Since this is already demonstrated in the ?rst example, it is not listed in detail.

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

<x l s : C h u n k i n g E l e m e n t x s i : t y p e=” xls:NElementLMChunkType” > <xls:ChunkingLM x s i : t y p e=” x l s : N o t I d e n t i f y i n g L L T y p e ” Name=” Weser”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i pt i o nE x a mp le T y p e”></ x l s : D e s c r i p t i o n> < x l s : L i n e P o s i t i o n> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> <g m l : p o s>2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : L i n e P o s i t i o n> <x l s : L a n d m a r k x s i : t y p e=”xls:GSOLMType ” S p a t i a l R e l a t i o n=” a t ” Name= ” Wilhelm?Kaisen?Bruecke”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i p t io n E x am p le T yp e”></ x l s : D e s c r i p t i o n> < x l s : P o i n t P o s i t i o n> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : P o i n t P o s i t i o n> </ x l s : L a n d m a r k> </ xls:ChunkingLM> </ x l s : C h u n k i n g E l e m e n t> < x l s : L a s t I n t e r s e c t i o n x s i : t y p e=” x l s : S t a n d a r d I n t e r s e c t i o n T y p e ” T u r n D i r e c t i o n=” l e f t ”> [...] </ x l s : L a s t I n t e r s e c t i o n> <x l s : C h u n k e d S e g m e n t s> [...] </ x l s : C h u n k e d S e g m e n t s> </ xls:ChunkedManeuver> <xls:ChunkedManeuver x s i : t y p e=” xls:ChunkType ” i d=”C3” a c t i o n T y p e=” A d v i s o r y ” NumberOfPassedDP=” 8 ”> [...] </ xls:ChunkedManeuver>

54

4.3. EXAMPLE 3: COMPETING BRANCHES The chunking element of the type xls:RoadHierarchyChunkType requires an additional chunking element which identi?es 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 provide the same information.
52 53 54 55 56 57 58 59 60 61 62 63 64 65
<x l s : C h u n k i n g E l e m e n t x s i : t y p e=” xls:RoadHierarchyChunkTyp e ” LevelName=” B75”> <x l s : C h u n k i n g E l e m e n t x s i : t y p e=” xls:PointLMChunkType”> <xls:ChunkingLM x s i : t y p e=” xls:StreetnameLMType ” Name=” K o r n s t r a s s e ”> < x l s : D e s c r i p t i o n x s i : t y p e=” x l s : L M D e s c r i pt i o nE x a mp le T y p e”></ x l s : D e s c r i p t i o n> < x l s : P o s i t i o n A t I n t e r s e c t i o n uom=” deg ”>90</ x l s : P o s i t i o n A t I n t e r s e c t i o n> </ xls:ChunkingLM> </ x l s : C h u n k i n g E l e m e n t> </ x l s : C h u n k i n g E l e m e n t> <x l s : C h u n k e d S e g m e n t s> [...] </ x l s : C h u n k e d S e g m e n t s> </ 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, even though an instruction requiring to count eight intersections is of questionable adequacy.

4.3 Example 3: Competing branches
The last example contains a single maneuver describing the action at a complex intersection with competing branches. The out–going branch of the route competes with another road. Therefore, an ordering concept has to be introduced. In the element xls:JunctionCategory, an ordering concept is used that describes the turn unambiguously. A way?nder is told to take the second exit (passing one exit) on her right. Additionally the exact con?guration of the route is provided to give the way?nder an exact picture of the spatial con?guration.
1 2 3 4 5
<xls:XManeuver i d=”x” a c t i o n T y p e=”Turn ” d i r e c t i o n O f T u r n=” Right ” j u n c t i o n T y p e =” I n t e r s e c t i o n ” > <x l s : M a n e u v e r P o i n t> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : M a n e u v e r P o i n t>

55

Ostheimer Str.

Ruegheimer Str.

Ringstr.

Poststr. Obere Torstr.

Figure 4.3: Map of the route in example 3. It is based on a map provided by www.de.map24.com in March 2006.

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

<x l s : J u n c t i o n C a t e g o r y x s i : t y p e=” x l s : C o m p e t i n g B r a n c h e s T y p e ” numberExitsToPass=” 1 ” T u r n D i r e c t i o n=” r i g h t ”> <x l s : R o u t e B r a n c h S t r e e t n a m e=” Ruegheimer S t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>130</ x l s : A n g l e> </ x l s : R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” P o s t s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>45</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” Ostheimer S t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>190</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> <x l s : N o R o u t e B r a n c h S t r e e t n a m e=” R i n g s t r a s s e ”> <x l s : A n g l e uom=” d e g r e e ”>280</ x l s : A n g l e> </ x l s : N o R o u t e B r a n c h> </ x l s : J u n c t i o n C a t e g o r y > <x l s : P r e v i o u s S e g m e n t S t r e e t n a m e=” Obere T o r s t r a s s e ”> <x l s : D i s t a n c e v a l u e=” 10 ”></ x l s : D i s t a n c e> <x l s : T r a v e l T i m e>P1Y2M3DT10H30M12 . 3 S</ x l s : T r a v e l T i m e> <x l s : B o u n d i n g B o x> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> <g m l : p o s>1 2 2 . 4 5 2 3 7 2 4 3 6 3 7 . 7 7 2 5 8 9 2 7 1 3</ g m l : p o s> </ x l s : B o u n d i n g B o x> </ x l s : P r e v i o u s S e g m e n t> </ xls:XManeuver>

An instruction based on this data could, for example, be: “Take the second branch on your right.”

5 Schema
1 2
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF?8” ?> <schema x m l n s : g m l=” h t t p : //www. o p e n g i s . n e t / gml ” x m l n s : x l s=” h t t p : //www. o p e n g i s . n e t / x l s ” xmlns=” h t t p : //www. w3 . o r g /2001/ XMLSchema” t a r g e t N a m e s p a c e=” h t t p : //www. o p e n g i s . n e t / x l s ” e l e m e n t F o r m D e f a u l t=” q u a l i f i e d ”> <i m p o r t namespace=” h t t p : //www. o p e n g i s . n e t / gml ” s c h e m a L o c a t i o n=” g m l 4 x l s . xsd ” /> <i n c l u d e s c h e m a L o c a t i o n=”ADT. xsd ” /> <i n c l u d e s c h e m a L o c a t i o n=” ADT Navigation . xsd ” /> < !?? B a s i c e l e m e n t ?? > <e l e m e n t name=” XManeuverList ” t y p e=” xls:XRouteMa ne u ve rL ist T yp e ” /> < !?? General Types ?? > <complexType name=” XRouteManeuverListType”> <a n n o t a t i o n> <d o c u m e n t a t i o n>Extended v e r s i o n o f t h e A b s t r a c t M a n e u v e r L ist T y pe . D e f i n e s a l i s t o f t r a v e l maneuvers ( c h a p t e r 5 . 3 ) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : R o u t e M a n e u v e r L i s t T y p e ”> <s e q u e n c e> <e l e m e n t name=” S t a r t i n g M a n e u v e r ” t y p e=” x l s : X S t a r t i n g M a n e u v e r T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Element d e s c r i b i n g t h e s t a r t i n g maneuver ( chapter 5 . 3 . 1 ) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=”EndManeuver” t y p e=” xls:XEndManeuverType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Element d e s c r i b i n g t h e s t a r t i n g maneuver ( chapter 5 . 3 . 1 ) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” XStartingManeuverType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A l l i n f o r m a t i o n about t h e f i r s t i n s t r u c t i o n o f a r o u t e ( chapter 5 . 3 . 1 ) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <s e q u e n c e> <e l e m e n t name=” Address ” t y p e=” x l s : A d d r e s s T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Element p r o v i d i n g t h e s t r e e t a d d r e s s o f t h e s t a r t i n g p o i n t . AddressType i s e x p l a i n e d i n t h e OpenLS s p e c i f i c a t i o n .

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

57

CHAPTER 5. SCHEMA
53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115
</ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> G e o g r a p h i c l o c a t i o n o f t h e s t a r t i n g p o i n t encoded a s gml:PointType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” Landmark ” t y p e=” x l s : S t a r t i n g P o i n t L M T y p e”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Landmark used f o r o r i e n t a t i n g t h e t r a v e l l e r a t the s t a r t i n g point </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=” i d ” t y p e=”ID” u s e=” r e q u i r e d ” /> <a t t r i b u t e name=” O r i e n t a t i o n ” t y p e=” gml:CompassPointEnumeration” u s e= ” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p e c i f y i n g t h e t r a v e l d i r e c t i o n a s an o r i e n t a t i o n encoded a s gml:CompassPointEnumeration . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> <a t t r i b u t e name=” R o a d D i r e c t i o n ” t y p e=” x l s : R o a d D i r e c t i o n T y p e ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The d i r e c t i o n t o t r a v e l a l o n g t h e f i r s t r o u t e segment from t h e s t a r t i n g p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ complexType> <complexType name=”XEndManeuverType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n>A l l i n f o r m a t i o n about t h e l a s t i n s t r u c t i o n o f a route ( chapter 5 . 3 . 2 ) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <s e q u e n c e> <e l e m e n t name=” Address ” t y p e=” x l s : A d d r e s s T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Element p r o v i d i n g t h e s t r e e t a d d r e s s o f t h e end p o i n t . AddressType i s e x p l a i n e d i n t h e OpenLS specification . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> G e o g r a p h i c l o c a t i o n o f t h e end p o i n t encoded a s gml:PointType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” Landmark ” t y p e=” xls:EndPointLMType ”>

58

116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177

<a n n o t a t i o n> <d o c u m e n t a t i o n> Landmark used f o r o r i e n t a t i n g t h e t r a v e l l e r a t the s t a r t i n g point </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P r e v i o u s S e g m e n t ” t y p e=” xls:XRouteSeg men t ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Segment l e a d i n g t o t h e end p o i n t </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=” i d ” t y p e=”ID” u s e=” r e q u i r e d ” /> <a t t r i b u t e name=” SideOfRoad ” t y p e=” x l s : S i d e O f R o a d T y p e ” u s e=” o p t i o n a l ” > <a n n o t a t i o n> <d o c u m e n t a t i o n> S p e c i f y i n g on which s i d e o f t h e road t h e d e s t i n a t i o n i s l o c a t e d . Using an OpenLS s i m p l e t y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ complexType> <complexType name=” XManeuverType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Extended v e r s i o n o f t h e A b s t r a c t M a n e u v e r L i st Ty p e . D e f i n e s a t r a v e l maneuver ( c h a p t e r 5.) </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t M a n e u v e r T y p e ”> <s e q u e n c e> <e l e m e n t name=” J u n c t i o n C a t e g o r y ” t y p e=” x l s : A b s t r a c t J u n c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> This e l e m e n t c o n t a i n s t h e c a t e g o r y o f t h e i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=”Landmark ” t y p e=” xls:Abstract1EDPLMType” minOccurs=” 0 ” maxOccurs=” unbounded ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> L i s t o f 1?element?DP landmarks a t t h i s d e c i s i o n p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P r e v i o u s S e g m e n t ” t y p e=” xls:XRouteSegme nt ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> This e l e m e n t c o n t a i n s t h e p r e v i o u s r o u t e segment </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <e l e m e n t name=”XManeuver ” t y p e=” xls:XManeuverType ” s u b s t i t u t i o n G r o u p=” x l s : M a n u e v e r ”>

59

CHAPTER 5. SCHEMA
178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241
<a n n o t a t i o n> <d o c u m e n t a t i o n> A t r a v e l maneuver . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <complexType name=”RoadNameChangeType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I n f o r m a t i o n about a road name change </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <s e q u e n c e> <e l e m e n t name=” P o i n t P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PointType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=”NewName” t y p e=” s t r i n g ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The new s t r e e t name </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ complexType> <complexType name=” XRouteSegment”> <a n n o t a t i o n> <d o c u m e n t a t i o n> RouteSegmentExtendedtype e x t e n s i o n by landmarks </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:RouteSegmentE xt e nd ed Typ e ”> <s e q u e n c e> <e l e m e n t name=”Landmark ” t y p e=”xls:NonDPPLMType” minOccurs=” 0 ” maxOccurs=” unbounded ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> L i s t o f point?landmarks a t t h i s d e c i s i o n p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=”RoadNameChange ” t y p e=” xls:RoadNameChangeType ” minOccurs=” 0 ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I n f o r m a t i o n about a s t r e e t name change </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> < a t t r i b u t e name=” S t r e e t n a m e ” t y p e=” s t r i n g ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S t r e e t n a m e o f t h e segment </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” Branch”>

60

242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304

<a n n o t a t i o n> <d o c u m e n t a t i o n> Type r e p r e s e n t i n g a branch o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <s e q u e n c e> <e l e m e n t name=” Angle ” t y p e=” gml:AngleType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Angle between branch and i n c o m i n g branch . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=” S t r e e t n a m e ” t y p e=” s t r i n g ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Name o f t h e s t r e e t / branch </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ complexType> < !?? J u n c t i o n s ?? > <complexType name=” A b s t r a c t J u n c t i o n T y p e ” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <s e q u e n c e> <e l e m e n t name=” RouteBranch ” t y p e=” x l s : B r a n c h ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Angle o f t h e o u t g o i n g branch i n r e s p e c t with t h e i n c o m i n g branch encoded gml:AngleType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” NoRouteBranch ” t y p e=” x l s : B r a n c h ” minOccurs=” 0 ” maxOccurs=” unbounded ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Angle o f t h e o t h e r b r a n c h e s i n r e s p e c t with t h e i n c o m i n g branch encoded gml:AngleType . One e l m e n t f o r each branch . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=”Name” t y p e=” s t r i n g ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I f t h e i n t e r s e c t i o n has a name . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ complexType> <complexType name=” AbstractNonCompetingType ” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t J u n c t i o n T y p e ” />

61

CHAPTER 5. SCHEMA
305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367
</ complexContent> </ complexType> <complexType name=” T I n t e r s e c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t N o n Co mp e t in g Ty p e”> < a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n T F T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Possible directions </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” F o r k I n t e r s e c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t N o n Co mp e t in g Ty p e”> < a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n T F T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Possible directions </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” S t a n d a r d I n t e r s e c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t N o n Co mp e t in g Ty p e”> < a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n S I T y p e” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Possible directions </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” CompetingBranchesType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent>

62

368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429

<e x t e n s i o n b a s e=” x l s : A b s t r a c t J u n c t i o n T y p e ”> < a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n C T y p e” u s e =” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Possible directions </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> < a t t r i b u t e name=” numberExitsToPass” t y p e=” n o n N e g a t i v e I n t e g e r ” u s e =” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> number o f e x i t s t o p a s s </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” LargeRoundaboutType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t J u n c t i o n T y p e ”> < a t t r i b u t e name=” numberExitsToPass” t y p e=” n o n N e g a t i v e I n t e g e r ” u s e =” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> number o f e x i t s t o p a s s </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” SmallRoundaboutType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t J u n c t i o n T y p e ”> < a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n S R T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Possible directions </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> < !?? Chunking ?? > <complexType name=”ChunkType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Type f o r chunks subsuming o t h e r r o u t e d i r e c t i o n s . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent>

63

CHAPTER 5. SCHEMA
430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488
<e x t e n s i o n b a s e=” x l s : A b s t r a c t M a n e u v e r T y p e ”> <s e q u e n c e> <e l e m e n t name=” ChunkedManeuver ” t y p e=” x l s : A b s t r a c t M a n e u v e r T y p e ” minOccurs=” 2 ” maxOccurs=” unbounded ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> L i s t o f t h e chunked maneuvers . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” ChunkingElement ” t y p e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Element s p e c i f y i n g t h e end o f t h e chunk . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L a s t I n t e r s e c t i o n ” t y p e=” x l s : A b s t r a c t J u n c t i o n T y p e ” minOccurs=” 0 ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S t r u c t u r e and t u r n a t l a s t i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” ChunkedSegments ” t y p e=” xls:RouteSegmentEx t en de dTy pe ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I n f o r m a t i o n s about t h e c o v e r e d s e g m e n t s </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> < a t t r i b u t e name=”NumberOfPassedDP ” t y p e=” p o s i t i v e I n t e g e r ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A t t r i b u t e f o r t h e number o f p a s s e d d e c i s i o n p o i n t s . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> < a t t r i b u t e name=” S t r e e t n a m e ” t y p e=” s t r i n g ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A t t r i b u t e f o r t h e s t r e e t n a m e , f o r example i f s t r e e t n a m e ? c h u n k i n g i s used </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <e l e m e n t name=” ChunkManeuver” t y p e=” xls:ChunkType ” s u b s t i t u t i o n G r o u p=” x l s : M a n u e v e r ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A chunked t r a v e l maneuver . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <complexType name=” AbstractChunkingElementType” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f a chunking e l e m e n t

64

489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552

</ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ complexType> <complexType name=” RoadHierarchyChunkType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <s e q u e n c e> <e l e m e n t name=” ChunkingElement ” t y p e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> < a t t r i b u t e name=” LevelName ” t y p e=” s t r i n g ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Name o f t h e s t r e e t h i e r a r c h y l e v e l </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=”NElementLMChunkType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Chunking u s i n g a l i n e a r landmark </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <s e q u e n c e> <e l e m e n t name=” ChunkingElement ” t y p e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ” minOccurs=” 0 ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=”ChunkingLM ” t y p e=” xls:AbstractNElementLMType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Identifying t h e chunk with a n?elments?landmark </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=”PointLMChunkType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent>

65

CHAPTER 5. SCHEMA
553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616
<e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <s e q u e n c e> <e l e m e n t name=”ChunkingLM ” t y p e=” xls:Abstract1EDPLMType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” StructureChunkType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> <s e q u e n c e> <c h o i c e> <e l e m e n t name=” T I n t e r s e c t i o n ” t y p e=” x l s : T I n t e r s e c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” F o r k I n t e r s e c t i o n ” t y p e=” x l s : F o r k I n t e r s e c t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” SRoundabout ” t y p e=” x l s : S m a l l R o u n d ab o u t Ty p e”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” LRoundabout ” t y p e=” x l s : L a r g e R o u n d a bo u t Ty p e”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I d e n t i f y i n g t h e end o f t h e chunk </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” NumericalChunkingTurnType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f an i n t e r s e c t i o n </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”>

66

617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680

< a t t r i b u t e name=” T u r n D i r e c t i o n ” t y p e=” x l s : T u r n D i r e c t i o n C h u n k T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Name o f t h e s t r e e t h i e r a r c h y l e v e l </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” N u m e r i c a l C h u n k i n g S t r a i g h t T y p e”> <a n n o t a t i o n> <d o c u m e n t a t i o n> I n d i c a t e s t o chunk s t r a i g h t t u r n s </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t C h u n k i n g E l e m e n t T y p e ”> </ e x t e n s i o n> </ complexContent> </ complexType> < !?? Landmarks ?? > <complexType name=” A b s t r a c t L M D e s c rip t io n Ty p e” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A b s t r a c t t y p e f o r a d e s c r i p t i o n o f a landmark </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ complexType> <complexType name=” LMDescriptionExampleType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Example t y p e f o r a d e s c r i p t i o n o f a landmark </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L M D e s c r i p t i o n T y p e ”> <s e q u e n c e> <c h o i c e> <e l e m e n t name=” P i c t u r e D a t a ” t y p e=” b a s e 6 4 B i n a r y ” minOccurs=” 0 ” > <a n n o t a t i o n> <d o c u m e n t a t i o n> P i c t u r e o f t h e landmark encoded with b a s e 6 4 </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P i c t u r e U r l ” t y p e=” s t r i n g ” minOccurs=” 0 ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> U r l o f a p i c t u r e o f t h e landmark . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” AbstractLandmarkType ” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l landmarks </ d o c u m e n t a t i o n> </ a n n o t a t i o n>

67

CHAPTER 5. SCHEMA
681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744
<s e q u e n c e> <e l e m e n t name=” D e s c r i p t i o n ” t y p e=” x l s : A b s t r a c t L M D e s c r i p t i o n T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Every landmark has t o be d e s c r i b e d . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> <a t t r i b u t e name=”Name” t y p e=” s t r i n g ” u s e=” o p t i o n a l ” /> </ complexType> <complexType name=” StartingPointLMType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Landmark f o r o r i e n t a t i o n a t a s t a r t i n g p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L a n d m a r k T y p e”> <c h o i c e> <e l e m e n t name=” P o i n t P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A s t a r t i n g p o i n t landmark can have a p o i n t ? l i k e geometry encoded a s gml:PointType . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L i n e P o s i t i o n ” t y p e=” g m l : L i n e S t r i n g T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A s t a r t i n g p o i n t landmark can have a l i n e a r ? l i k e geometry encoded a s g m l : L i n e S t r i n g T y p e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” A r e a P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A s t a r t i n g p o i n t landmark can have a a r e a ? l i k e geometry encoded a s gml:PolygonType . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> < a t t r i b u t e name=” O r i e n t a t i o n ” t y p e=” gml:CompassPointEnumeration ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> O r i e n t a t i o n o f landmark r e s p e c t i v e t h e s t a r t i n g p o i n t u s i n g gml:CompassPointEnumeration . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> < a t t r i b u t e name=” S p a t i a l R e l a t i o n ” t y p e=” x l s : S t a r t L M R e l a t i o n T y p e ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p a t i a l r e l a t i o n o f landmark and s t a r t i n g p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=”EndPointLMType ”>

68

745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806

<a n n o t a t i o n> <d o c u m e n t a t i o n> Landmark f o r o r i e n t a t i o n a t a end p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L a n d m a r k T y p e”> <c h o i c e> <e l e m e n t name=” P o i n t P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A end p o i n t landmark can have a p o i n t ? l i k e geometry encoded a s gml:PointType . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L i n e P o s i t i o n ” t y p e=” g m l : L i n e S t r i n g T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A end p o i n t landmark can have a l i n e a r ? l i k e geometry encoded a s g m l : L i n e S t r i n g T y p e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” A r e a P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> A end p o i n t landmark can have a a r e a ? l i k e geometry encoded a s gml:PolygonType . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> < a t t r i b u t e name=” O r i e n t a t i o n ” t y p e=” gml:CompassPointEnumeration ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> O r i e n t a t i o n o f landmark r e s p e c t i v e t h e s t a r t i n g p o i n t u s i n g gml:CompassPointEnumeration . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> < a t t r i b u t e name=” S p a t i a l R e l a t i o n ” t y p e=” xls:EndLMRelationType ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p a t i a l r e l a t i o n o f landmark and end p o i n t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> < a t t r i b u t e name=” SideOfRoad ” t y p e=” x l s : S i d e O f R o a d T y p e ” u s e=” o p t i o n a l ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p e c i f y i n g on which s i d e o f t h e road t h e end p o i n t landmark is l o c a t e d . Using an OpenLS s i m p l e t y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” Abstract1ElementLMType” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n>

69

CHAPTER 5. SCHEMA
807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870
The s u p e r t y p e o f a l l landmarks i d e n t i f y i n g o n l y one r o u t e element . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L a n d m a r k T y p e” /> </ complexContent> </ complexType> <complexType name=”Abstract1EDPLMType ” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l point?landmarks </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1Element LMTy pe ” /> </ complexContent> </ complexType> <complexType name=”AreaLM1Type ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l 1?e l e m e n t a r e a l landmarks </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1EDPLMType”> <s e q u e n c e> <e l e m e n t name=” P o l y g o n P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PolygonType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” AbstractNElementLMType” a b s t r a c t=” t r u e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l landmarks i d e n t i f y i n g o n l y one r o u t e element . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L a n d m a r k T y p e” /> </ complexContent> </ complexType> <complexType name=”AreaLMNType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l n?elements a r e a l landmarks </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:AbstractNElementLMType”> <s e q u e n c e> <e l e m e n t name=” P o l y g o n P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PolygonType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e>

70

871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935

</ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” AbstractLineLMType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> The s u p e r t y p e o f a l l t y p e r e p r e s e n t i n g a landmark with a l i n e a r ? l i k e f u n c t i o n . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:AbstractNElementLMType”> <s e q u e n c e> <c h o i c e> <e l e m e n t name=” P o l y g o n P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PolygonType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L i n e P o s i t i o n ” t y p e=” g m l : L i n e S t r i n g T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a g m l : L i n e S t r i n g T y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” I d e n t i f y i n g L L T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a l i n e a r ? l i k e f u n c t i o n , which i d e n t i f i e s t h e l a s t DP. </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L i n e L M T y p e ”> < a t t r i b u t e name=” S p a t i a l R e l a t i o n ” t y p e=” x l s : S p a t i a l R e l a t i o n L i n e a r I d e n t T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p a t i a l r e l a t i o n o f t h e l i n e a r landmark t o t h e r o u t e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” N o t I d e n t i f y i n g L L T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a l i n e a r ? l i k e f u n c t i o n , which i d e n t i f i e s t h e l a s t DP. </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” x l s : A b s t r a c t L i n e L M T y p e ”> <s e q u e n c e> <e l e m e n t name=”Landmark ” t y p e=” xls:Abstract1Element LMTy pe ”> <a n n o t a t i o n> <d o c u m e n t a t i o n>

71

CHAPTER 5. SCHEMA
936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000
Landmark t h a t i d e n t i f i e s t h e end o f t h e r e l a t i o n between r o u t e and l i n e a r f u n c t i o n landmark . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=”NonDPPLMType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a l i n e a r ? l i k e f u n c t i o n , which i d e n t i f i e s t h e l a s t DP. </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1Element LMTy pe ”> <s e q u e n c e> <c h o i c e> <e l e m e n t name=” P o i n t P o s i t i o n ” t y p e=” gml:PointType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PointType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L i n e P o s i t i o n ” t y p e=” g m l : L i n e S t r i n g T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a g m l : L i n e S t r i n g T y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P o l y g o n P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PolygonType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> </ s e q u e n c e> < a t t r i b u t e name=” S p a t i a l R e l a t i o n ” t y p e=” x l s : S p a t i a l R e l a t i o n N o n D P T y p e” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p a t i a l r e l a t i o n between landmark and r o u t e segment . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=”GSOLMType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a p o i n t ? l i k e f u n c t i o n , which b e l o n g s t o t h e c a t e g r o y g e n e r a l s a l i e n t o b j e c t . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1EDPLMType”> <s e q u e n c e> <c h o i c e> <e l e m e n t name=” P o i n t P o s i t i o n ” t y p e=” gml:PointType ”>

72

1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065

<a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PointType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” L i n e P o s i t i o n ” t y p e=” g m l : L i n e S t r i n g T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a g m l : L i n e S t r i n g T y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> <e l e m e n t name=” P o l y g o n P o s i t i o n ” t y p e=” gml:PolygonType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n encoded a s a gml:PolygonType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ c h o i c e> </ s e q u e n c e> < a t t r i b u t e name=” S p a t i a l R e l a t i o n ” t y p e=” x l s : S p a t i a l R e l a t i o n G S O T y p e ” u s e=” r e q u i r e d ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> S p a t i a l r e l a t i o n between landmark and r o u t e segment . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ a t t r i b u t e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” StreetnameLMType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a p o i n t ? l i k e f u n c t i o n , which b e l o n g s t o t h e c a t e g r o y s t r e e t n a m e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1EDPLMType”> <s e q u e n c e> <e l e m e n t name=” P o s i t i o n A t I n t e r s e c t i o n ” t y p e=” gml:AngleType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> P o s i t i o n a t i n t e r s e c t i o n encoded a s a gml:AngleType </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> <complexType name=” StructureLMType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> R e p r e s e n t i n g a landmark with a p o i n t ? l i k e f u n c t i o n , which b e l o n g s t o t h e c a t e g r o y s t r u c t u r e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> <complexContent> <e x t e n s i o n b a s e=” xls:Abstract1EDPLMType”> <s e q u e n c e> <e l e m e n t name=” I n t e r s e c t i o n ” t y p e=” x l s : A b s t r a c t J u n c t i o n T y p e ”> <a n n o t a t i o n>

73

CHAPTER 5. SCHEMA
1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131
<d o c u m e n t a t i o n> Type o f i n t e r s e c t i o n encoded a s a A b s t r a c t J u n c t i o n T y p e </ d o c u m e n t a t i o n> </ a n n o t a t i o n> </ e l e m e n t> </ s e q u e n c e> </ e x t e n s i o n> </ complexContent> </ complexType> < !?? S i m p l e Types ?? > <simpleType name=” RoadDirectionTyp e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e t u r n d i r e c t i o n s a l o n g a road at the s t a r t of a route . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” s t r a i g h t ” /> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” StartLMRelationType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s o f a s t a r t landmark t o the s t a r t i n g point of a route . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” t o w a r d s ” /> <e n u m e r a t i o n v a l u e=”away ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” EndLMRelationType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s o f a end landmark t o the d e s t i n a t i o n of a route . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” o p p o s i t e ” /> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” S p a t i a l R e l a t i o n L i n e a r I d e n t T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s o f a l i n e a r ? f u n c t i o n landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” a l o n g ” /> <e n u m e r a t i o n v a l u e=” a f t e r ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” SpatialRelationNonDPType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s o f a l i n e a r ? f u n c t i o n landmark t o t h e r o u t e . </ d o c u m e n t a t i o n>

74

1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197

</ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” p a s s ” /> <e n u m e r a t i o n v a l u e=” c r o s s ” /> <e n u m e r a t i o n v a l u e=” t h r o u g h ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” SpatialRelat ion G S OTy p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” a t ” /> <e n u m e r a t i o n v a l u e=” a f t e r ” /> <e n u m e r a t i o n v a l u e=” b e f o r e ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” TurnDirectionTFType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” T u r n D i r e c t i o n S I T y p e ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> <e n u m e r a t i o n v a l u e=” s t r a i g h t ” /> <e n u m e r a t i o n v a l u e=” s l i g h t L e f t ” /> <e n u m e r a t i o n v a l u e=” s l i g h t R i g h t ” /> <e n u m e r a t i o n v a l u e=” s h a r p L e f t ” /> <e n u m e r a t i o n v a l u e=” s h a r p R i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” TurnDirectionCType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” TurnDirectionSRType”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s landmark t o t h e r o u t e .

of a linear?function

of a linear?function

of a linear?function

of a linear?function

of a linear?function

75

CHAPTER 5. SCHEMA
1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218
</ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” s t r a i g h t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> <simpleType name=” TurnDirectionChunkType ”> <a n n o t a t i o n> <d o c u m e n t a t i o n> Enumeration o f p o s s i b l e s p a t i a l r e l a t i o n s o f a l i n e a r ? f u n c t i o n landmark t o t h e r o u t e . </ d o c u m e n t a t i o n> </ a n n o t a t i o n> < r e s t r i c t i o n b a s e=” s t r i n g ”> <e n u m e r a t i o n v a l u e=” l e f t ” /> <e n u m e r a t i o n v a l u e=” r i g h t ” /> </ r e s t r i c t i o n> </ simpleType> </ schema>

76

Bibliography
[1] Bychowski, T. (2003): OpenGIS Location Services (OpenLS): Part 6 – Navigation Service. OGC Implementation Speci?cation 03-007r1 (Version 0.5.0). Open GIS Consortium Inc. [2] Cox, S., Daisey, P., Lake, R., Portele, C., Whiteside, A. (2004): OpenGIS Geography Markup Language (GML) Implementation Speci?cation 03105r1 Version 3.1.0. Open Gis Consortium Inc. [3] Dale, R., Geldof, S., Prost, J.-P. (2003): CORAL: Using natural language generation for navigational assistance. In: Oudshoorn, M. (Ed.), Proceedings of the 26th Australasian Computer Science Conference (ACSC2003), Adelaide, Australia. [4] Denis, M. (1997): The description of routes: A cognitive approach to the production of spatial discourse. Cahiers de Psychologie Cognitive, 16:409458. [5] Denis, M., Pazzaglia, F., C.Cornoldi & Bertolo, L. (1999): Spatial discourse and navigation: An analysis of route directions in the city of Venice. Applied Cognitive Psychology 13:145-174. [6] Freed, N., Borenstein, N., (1996): Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. Internet Engineering Task Force. [7] Hansen, S., Richter, K.-F., Klippel, A. (2006): Landmarks in OpenLS a data structure for cognitive ergonomic route directions. In M. Raubal, H. Miller, A. U. Frank, M. F. Goodchild (Eds.), Geographic Information Science - Fourth International Conference, GIScience 2006 (pp. 128–144). Springer, Berlin. [8] International Organization for Standardisation (ISO), (2001): ISO 19118 Draft International Standard: Geographic Information – Encoding. Document ISO/TC211 N1136, Technical Committee 211, ISO Secretariat, Geneva, Switzerland. [9] Klippel, A, Dewey, C., Knau?, M., Richter, K.-F., Montello, D. R., Freksa, C., Loeliger, E.-A. (2004): Direction Concepts in Way?nding Assistance Systems. In: Baus, J., Kray, C., Porzel, R. (Eds.), Workshop on Arti?cial Intelligence in Mobile Systems 2004 (AIMS’04), SFB 378 Memo 84, Saarbr¨ cken, pp. 1-8. u

77

Bibliography [10] Klippel, A., Hansen, S., Davies, J., Winter, S. (2005): A High-Level Cognitive Framework For Route Directions. Proceedings of SSC 2005 Spatial Intelligence, Innovation and Praxis: The national biennial Conference of the Spatial Science Institute. September 2005. Melbourne:Spatial Science Institute. ISBN 0-9581366-2-9 [11] Klippel, A., Richter, K.-F., Hansen, S. (2005): Structural salience as a landmark. Workshop Mobile Maps 2005, Salzburg, Austria. [12] Klippel, A., Tappe, T., Habel, C. (2003): Pictorial representations of routes: Chunking route segments during comprehension. In C. Freksa, W. Brauer, C. Habel, and K.F. Wender (Eds.), Spatial Cognition III. Routes and Navigation, Human Memory and Learning, Spatial Representation and Spatial Learning (pp. 11-33). Springer, Berlin. [13] Klippel, A., Tappe, T., Kulik, L., Lee, P.U. (2005): Way?nding choremes - A language for modeling conceptual route knowledge. Journal of Visual Languages and Computing, 16(4):311-329. [14] Klippel, A. Tenbrink, T., Montello, D. R. (submitted): The role of structure and function in the conceptualization of directions. [15] Lovelace, K. L., Hegarty, M., and Montello, D. R. (1999). Elements of good route directions in familiar and unfamiliar environments. In C. Freksa & D. M. Mark (eds.), Spatial Information Theory - Cognitive and Computational Foundations of Geopraphic Information Science, (pp. 65-82). International Conference COSIT, Berlin: Springer. [16] Mabrouk, M. (2005): OpenGIS Location Services (OpenLS): Core Services. OGC Implementation Speci?cation 05-016 Version 1.1. Open GIS Consortium Inc. [17] Michon, P.-E., Denis, M. (2001): When and why are visual landmarks used in giving directions? In: Montello, D.R. (Ed.), Spatial Information Theory. Foundations of Geographic Information Science (pp. 292-305). International Conference, COSIT 2001. Springer, Berlin. [18] The Open Geospatial Consortium (OGC). http://www.opengis.org. [19] Richter, K.-F., Klippel, A. (2005): A model for context-speci?c route directions. In: Freksa, C., Knau?, M., Krieg-Br¨ ckner, B., Nebel, B., u Barkowsky, T. (Eds.), Spatial Cognition IV. Reasoning, Action, and Interaction: International Conference Spatial Cognition 2004 (pp. 58-78). Springer, Berlin.

78


赞助商链接

更多相关文章:
德国学校及专业排名
Hochschule Bremen (不来梅高等专业学院) 52. Hochschule für Künste Bremen (不来梅艺术学院) 53. International University Bremen (不来梅国际大学) 54. Universit...
德国所有大学的联系方式
t Bonn Regina-Pacis-Weg 3, 53113 Bonn,Germany Tel:0228/731 Fax:0228/737075 Internet: http://www.uni-bonn.de/ Universit?t Bremen Bibliotheksstra?e ...
[德国大学]德国UNI-ASSIST成员高校名单
Universit?t Potsdam 不来梅州 17. Hochschule Bremerhaven 18. Universit?t Bremen 汉堡州 19. HafenCity Universit?t Hamburg 20. Hamburger Fern-Hochschule 21....
留学申请---德国所有被承认的高校名称
t Bonn Universit?t Braunschweig Universit?t Bremen Universit?t Dortmund Universit?t Dusseldorf Universit?t Erlangen Universit?t Frankfurt Universit?t Gesamt...
德国十一所精英大学名单
Berlin t 柏林自由大学 Humboldt-Universit? zu Berlin t 柏林洪堡大学 Universit? Bremen t 不来梅大学 Technische Universit? Dresden t 德累斯顿工业大学 Ruprecht-...
与同济大学有合作协议的国外知名院校名单(至2014年11月)-校外事办...
t Bremen Technische Universit?t Darmstadt Technische Universit?t Dresden Friedrich-Alexander-Universit? t Erlangen-Nürnberg 弗莱堡大学 汉堡大学 汉诺威大学 汉诺威...
德国大学名单
Braunschweig / Wolfenbüttel Bremen H: Hochschule Bremen Bremen HfK: Hochschule fü r Künste Bremen BremenJU: Jacobs University Bremen Bremen U: Universit...
德国大学名录
t Bremen 国立 60.不来梅哈芬应用技术大学 Bremerhaven H: Hochschule Bremerhaven 国立 61.德国 布鲁 赫萨 尔 国际大 学 Bruchsal IU: International University in...
教育部认可的德国学校
t Dortmund Dresden HfBK: Hochschule für Bildende Künste Dresden 国立 国立 ... 国立 国立 国立 国立 国立 国立 私立、国家认 可 Bremen U: Universit?...
Wittstock_npAuMethanolCoupling_Science_图文
umer Universit?t Bremen 252 PUBLICATIONS 7,263 CITATIONS SEE PROFILE Available from: Arne Wittstock Retrieved on: 25 August 2016 Nanoporous Gold Catalysts ...
更多相关标签:

All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。
甜梦文库内容来自网络,如有侵犯请联系客服。zhit325@126.com|网站地图