+ Workshop on Position-Dependent Information Services

Functional requirements for in-car information services.

Carl Stephen Smyth

Navigation Program Manager

Microsoft Automotive Business Unit

Introduction

My experience in position-dependent services comes from the field of in-car services. These centre in two areas: route-finding and filtered search for things (addresses, buildings, services, points of interest) near a location or along a route. I believe that much of this experience can be generalized. In particular, the separation of concepts derived from human mental representations from those based on database representations of attributed geometry have proved to be very helpful. This paper motivates the selection of a small number of representational types and a like number of functional requirements based on a clear separation between the human and database representational realms. These types and requirements are derived from several years of development work within the ISO TC204 SWG 3.4 Traveller Information and Control Systems (TICS) API effort.

Philosophical prelude

Geography, point-of-view-, and mobility are human concepts.

The ordinary bricks and mortar of network communications, tweaked a bit to handle bandwidth restrictions, power and weight limitations, fading, multipath, handoff, national and regional frequency allocations and the specifics of owned technology are easily understood in the context of mobile and location-based information services. Likewise, we understand how to measure the coordinates of mobile devices and communicate geometric information.

There are three new elements in position-dependent services. They stem from the essence of being mobile humans. Their nature is very familiar but that very familiarity presents serious challenges to the successful design of interoperable position-dependent information services.

The first new element is geography itself. Geography is the human mental concept of a collection of linguistically- and culturally-recognized entities that sit on or near the earth’s surface in some spatial and temporal relationship to one another. Extraterrestrials would understand material properties and physical form – they would not understand human geography. Being human is required to understand geography, that is, to give a name to a recognized entity and understand the relationships between them. It is a common misconception to think that geography is “just there.” It is not. It’s learned; it’s tightly coupled with language; it has a strong cultural and regional component.

Second, human understanding of geography is complicated by the fact that we always experience it from a particular point-of-view. This means that some things very conspicuous (things close to us) and some things very inconspicuous (things far from us). It is very different from the uniform information density and experience of a map or cartographic database. A person’s point-of-view not only affects his or her relationship to geographic entities but also induces new and changing relationships between those entities themselves. It takes time and effort to change point of view.

Much of the value of mobile and location-based services bear on improving the efficiency or quality of the third new element: mobility – the process of changing point-of-view within a geography. Personal mobility can be very complex. There are few constraints on how we may move from one point of view to another.

Humans innately understand the fundamental relationships between geography, point-of-view, and mobility.

Some examples:

“Do I have time to meet my team members for a beer?”

“Find a hotel on the other side of town.”

“I want to send it home. My address is Slievenamon, Altaron, Glanfoyle, County Cork, Ireland. No, there is no postal code. Oh, and the road in front of the house has no name. It’s the second house up on the right after you pass the hospital. The one a low white wall with four pillars.”

“I don’t speak Japanese. I can’t tell you where it is, but I have a map he faxed me. Please take me there”

“Guide me to a park on the river bank where we could have a picnic.”

“Find a parking place.”

It would be good to separate the human representation from the database representation in a way that makes the engineering issues clear. At a minimum, it is necessary to treat the semantic concepts directly.

Semantic translation is unavoidable but can be contained.

Just for a moment consider why it isn’t possible to simply convert to and from human mental representations on the fly from a single database representation.

First, selection of “features of interest” by a mobile person almost always involves reference to either location or specific geographic entities. The names and class membership of these features is quite variable as reference to any two maps (or people) from the same area will demonstrate. The classes in particular are very idiosyncratic. Database representations are often derived from the nature of the application that originally funded their creation, not the needs of a position-dependent information service and certainly not the mental concepts of a specific user. Nevertheless, identity of geographic features is clear to the mobile human. Even two humans of different background can usually negotiate a workable common understanding of what is meant by a geographic reference. This semantic translation is a much more difficult but necessary process for software working against database content.

Sometimes the suggestion is made that all that is required is geometry. This “whatever is there is what I mean” approach only postpones the selection of a database reference linked to a geographic reference. Semantic translation is necessary to make this linkage. Semantic translation is language, culture, and location-dependent. Geography is as easily understood and as difficult to process as natural language because they are inextricably linked. That “language structures space” is a famous conclusion of linguistics and computational geography [Talmy, 1983].

Basic services centre on correspondences between databases and human geographic concepts .

The most primitive services involve establishing a link between some geometry, for example position information sensed by a mobile device, and some modelled entities in a database. The presentation of guidance information giving information on landmarks and manoeuvres, for example, is based on the selection of a destination, determination of the current location with respect to a database element, and the generation of a path through the database representation that will be comprehensible to the human in terms of recognized entities in the real world. The most elementary services are those involved with the designation of database-geography correspondences and the calculation of information products for use in the real world from a database representation.

The following sections examine some details of some of the basic functionality as a prelude to the definition of twenty fundamental service components useful for in-car position-dependent services.

Privacy concerns imply simple and standardised architectural solutions.

The essential concern with mobile devices that are connected and position-aware is that of identifying irrelevant and perhaps highly personal behaviour of a person through a spatio-temporal trajectory relayed from the device to an information store. In the car, it is not sufficient to simply remove identification of the device because a given trajectory can often be associated with a specific person by matching other location-based information. For example, if a vehicle leaves my garage and travels to a certain bank and then returns to my garage, it is not far-fetched to infer that I went to that bank, even though there might be no explicit identification associated with the trajectory.

A primary application of telemetered position and speed information for in-car computing is to help predict the experience of other drivers travelling under similar conditions, either contemporaneously or in the future. That information can be aggregated to the link level in space and to rather large spans in time, at least half an hour and probably several hours in length for much of the day. This aggregation can be applied in the vehicle, before exporting it off-board. It is also possible to decimate the data – to save only every n-th link aggregate – before transmission. The combination of identity removal, aggregation in space and time, and decimation, applied in a well understood and standard way at the mobile device can give consumers confidence that their individual behaviour cannot be recovered.

Privacy concerns can be partially offset by a perceived return on the value of shared information.

Users of position-dependent information services must see some value in those services if they are to want them. Given a simple model of the nature of mobility information that their travel may generate, it may be possible to create a rationale for the partial payment for those services by that mobility information.

Some generalisations beyond the requirements for in-car applications

Positioning requires semantic translation

The requirement is to turn some human-meaningful language or gesture into a database reference. This almost always requires semantic translation. The burden can be placed on the user or mediated by automated semantic translation. A related capability is the generation of human-meaningful language describing some database element. Either of these applications of semantic translation (between the individualised human concepts, usually expressed in natural language, and a fixed database representation) requires explicit treatment. Assuming that this somehow gets taken care of in the application is likely to lead to disappointment.

Identification and selection must be negotiated and involves semantic translation

It’s difficult to make an unambiguous reference to an entity out there in geographic space. It’s harder yet to negotiate a set of names, classes and relationships that uniquely match a database reference. One of the most awkward aspects of today’s in-car information systems is the selection of services, points of interest, addressed buildings, and other waypoints and destinations

Communicating location and other geometry is well-understood

Geometry is surprisingly easy and relatively unimportant. It is just an attribute of entities. As noted in the workshop announcement, well-developed mechanisms exist to do this with whatever degree of precision required. It is both unnecessary and unwise to invent new ways of doing this. There are surprising levels of complexity in specifying and inter-converting between location descriptions given with respect to different spatial reference systems. Many of the services contemplated for in-car applications such as adaptive cruise control, headlight aiming, and lane control require the finesse of an expert geodesist to achieve centimetre-level relative positions. But the techniques for doing this already exist and are well defined within a number of groups [OGC, ISO TC211, EPOCS].

Some high level functional requirements focused on the automobile

The following sections define nineteen element classes that require representation for exchange between mobile devices and fixed sites for a restricted range of high-level in-car position-dependent services. These element classes are indicated in bold italic. I estimate that they represent about one-fifth of the total number of functional requirements for position-dependent services as a whole. The in-car segment is a good starting point for understanding position-based information services, because mobility is very constrained and the capabilities of the in-car platform (power, weight limitations) are not. Of course, in the long term, the personal devices are going to be more important because of their order-of-magnitude greater numbers.

Conceptually, there are three realms of representation:

1) Human conceptualisation of the real world as expressed in geographic references

2) Database representations of artefacts of the real world, which may be accessed via database references

3) Presentation, where media associated with database references (presentation elements) are retrieved for presentation to the human senses.

Segmenting the representational architecture this way cleanly defines the interfaces between the human-cantered geographic representation and the more familiar engineering representations of database and presentation.

SEMANTIC SERVICES

The implementation of the first of these bullet points is extraordinarily sensitive to the variations concepts of geography derived from language and culture. To be successful, it is essential to establish flexible mechanisms for semantic translation of geographic references. This requires agreement at an architectural level as to the nature and interpretation of geographic references. Our experience has shown that simplistic an assumption such as the universal existence of hierarchical relationships between geographic entities is bound to lead to technological dead ends. This assumption that there is exactly one breakdown of (for example) a country into administrative regions that contain smaller administrative regions and ultimately places, streets, and houses is wrong enough and wrong often enough to be unworkable in practice.

n Interactively convert a human-understandable geographic reference to a location, address, point-of-interest, or service into a database reference.

This is another critical capability. It is rather difficult (and application-specific) to come up with the best geographic reference. For example, a mobile user might be at a service location in the database that in human terms is better described as “PASS machine in Patrick’s street by Carey’s Lane” than “cash machine in Cork, Ireland” even though both are correct.

n Convert a database reference to a geographic reference

PRESENTATION SERVICES

This again hides a lot of implementation, but the requirement is to retrieve appropriate things to render, not to do the rendering.

n Retrieve presentation elements according to geographic region and type of content, such as cartographic display, 3D display, text-to-speech, text display, HTML, audio, or video.

Sometimes it is necessary to retrieve media corresponding to a database reference.

n Convert a database reference into presentation elements that can be rendered graphically or as text, audio, video or other multimedia.

MOBILITY SERVICES

This is necessary if the on-board software is using on-board information to navigate.

n Accept time-stamped navigation sensor inputs

These are normal sensed coordinates from navigation, either on- or off-board, to be used on-board.

n Specify coordinates at time

These are direct references to elements that can be located in the on- or off-board database. For example, “…reached checkpoint 3 at 16:45….”

n Specify database reference at time

This is a crucial operation, known in the GIS world as reverse geocoding.

n Convert coordinates (with respect to a spatial reference system) to database reference

This is normally straightforward, since the coordinates can be computed or retrieved from the geometry.

n Convert database reference to coordinates

In in-car applications, information about the road network is often provided in a way that maps to multiple database elements. For example, there may be slow traffic northbound on the A2 from Dortmund to Bielefeld. This involves a number of links on that road.

n Convert location reference to database reference list

This is needed to properly dispatch information to the MMI on manoeuvres and route-specific information such as signs and landmarks.

n Predict time of arrival at a database reference

These capabilities are needed to communicate the characteristics of the locality (with regard here to automobile travel) and the characteristics of the driver.

n Personalize behaviour of system

n Specify driving characteristics of roads of various classes and situations

n Specify driver preferences and habits

It is sometimes necessary to retrieve media suitable to present the route itself.

n Get the geometry (set of presentation elements) of a planned route

This is the key requirement for route guidance. The information consists of database references to signs, services, landmarks, manoeuvres and other relevant elements. In combination with the requirement to predict the time of arrival at a database reference, this allows the MMI to present information and instructions at the appropriate time.

n Get route information and manoeuvre instructions from the system for driving a selected route

Most existing systems operate in a “single active route” mode where they pre-calculate or retrieve a route to a single destination. If the actual motion of the vehicle deviates from the route, then the system can either generate instructions to return to the planned route or retrieve or calculate a new route. In this case, it is necessary to know whether the vehicle is on or off route.

n Determine when the driver has deviated from a route

This is the essence of defining a single route. These database references are usually obtained by converting coordinates to a database reference (starting point) and geographic reference(s) to a database reference(s) (waypoints and destination).

n Indicate starting database references, intermediate waypoint database references and a final destination or set of destination database references.

Systems offering route guidance incorporating updated information on the status of roads due to road works, congestion, accidents, weather, or special driving restrictions require the ability to accept and integrate dynamic information.

n Accept new information about the status of roads

Some changes relate to the possibility (perhaps time-dependent) of driving in a certain direction along a sequence of links.

n Specify conditions on manoeuvres

Some changes relate to the changed driving characteristics of individual links, or chains of links. This is typically the case when there is traffic congestion, bad weather, or an accident.

n Specify properties of links or nodes in a network representation of roads

Some changes relate to the availability of services, access to services, or access to points of interest.

n Specify properties of points-of-interest or services

Glossary

Coordinates: Numerical values that define a location in a cartographic grid system or other spatial reference system.

Database Reference: A position defined with respect to a link or node in a database representation of the drivable road network.

Destination: A database reference to driving goal.

Geographic Reference: A human-understandable specification of a real-world entity, usually one with a name or other unique identification.

Geographic Region: A geographic reference to some interesting place or area of activity.

Link: A database element that represents a stretch of road between two junctions.

Location Reference: A specialised geographic reference used for the purpose of locating information pertaining to a stretch of road.

Semantics: The interpretation of the content of a representation, such as the human-centred geographic reference on the one hand and a canonical storage representation of a database reference on the other hand. Semantic translation is the conversion between one representation and another, preserving as much meaning as possible.

Manoeuvre Instruction: A media element associated with a database reference, suitable for guiding a driver toward a chosen destination.

Manoeuvre: An act by the driver requiring recognition of a real-world feature and corresponding control of the automobile to move along a specified path in reference to that feature.

Navigation Sensor: An on-board device that senses something about the position, orientation, or time rates of change of position or orientation of a mobile device.

Node: A database element that represents the point where links may (but are not required to) join.

Point-of-interest: A database reference corresponding to some geographic feature of potential interest to a mobile human.

Presentation: The process of rendering media elements so that they may be perceived by a human’s senses.

Presentation Element: A media element stored with a database reference and suitable for presentation.

Properties of links or nodes: Application-defined information (such as speed of travel history in each direction) useful for delivering mobility-related services.

Properties of points-of-interest or services: Application-defined information (such as schedules, product availability) useful for delivering mobility-related services.

Road: A sequence of database references to drivable elements (links and nodes) with a humanly recognisable unity derived from (for example) a single name given by a naming authority extending over a region or a physical unity defining a single physical entity (same arrangement of lanes and type of construction).

Route: A planned path to a destination, possibly passing through some intermediate waypoints.

Route Information: Properties of a route, such as the expected travel time, fuel required, tolls, or other information.

Service: A database reference corresponding to a geographic entity offering some good or service.

Spatial Reference System: A geodetic system for interpreting geographic and grid coordinates.

Timestamp: A precise relative time assigned to navigation data, internally consistent for a single mobile device.

Mobility: Having to do with changing the location or point of view of a mobile device.

Reference

Talmy, L. 1983. “How Language Structures Space.” In H. Pick and L. Acedolo (Eds.), Spatial Orientation: Theory, Research and Application. New York: Plenum Press.