Navigation is core to mobile location services. Navigation tools allow you to locate yourself and your destination, generate directions, and find POIs along the way or at your final destination. These tools are available today, both on the World Wide Web and in onboard navigation systems, turn -key in-vehicle systems such as Magellan's Neverlost, and others. See Figure 11.1 for a sample onboard navigation system available in Europe from Blaupunkt.
Figure 11.1. Blaupunkt Radio Navigation System TravelPilot DX-R70 Titan. 2002 Bosch Group.
So what is the value of an offboard system that has a thin client and does its spatial processing remotely? Because navigation and spatial analysis are core to the many more advanced location services that require remote processing, such as concierge , emergency assistance, and travel services, it does not make sense for spatial processing to happen in the vehicle for navigation and remotely for other services.
The results of spatial search must be consistent. Having spatial analysis split might allow the user to generate different driving directions for the same origin and destinations as those generated by a call center operator, an embarrassing situation if the user is calling because he or she is lost and needs help.
Thin clients are inherently less expensive to support than thick clients. Thin client applications can be constantly improved from the server side without upgrading software on the client. Because map data can be as large as 10 GB or more and changes frequently, this is important. Furthermore, mobile devices that are not in-vehicle units do not have the power supply and storage space ideal for visual navigation system.
Most important, offboard systems are able to leverage real-time information about traffic conditions to dynamically route a user around problem areas. In parts of Europe, traffic information is broadcast as data over FM radio. This information is typically from free public sources, and the service is not consistent in availability and quality. A better solution is to leverage information from a traffic information provider that has been normalized and aggregated from many sources.
Of the many possible mobile location service applications, traffic is one that has generated a tremendous amount of interest. People are willing to pay for services that will save them time ”and traffic information is one of them. To effectively use traffic information requires integration into your navigation system.
Awareness of traffic conditions allows the development of dynamic rather than static navigation applications. Before a route between two points is returned to a user, a check is made to see if there is traffic that will impact their proposed route. If so, a number of calculations need to be performed to decide whether it is best to route the user through the traffic or if an alternate route might be faster. A dynamic navigation system also knows where a user is on the route, so if the system receives notification that an incident has occurred on a route segment that has not yet been traversed, it is able to notify the user and suggest alternates. The quality of the dynamic navigation system is dependent on the data available in the traffic report and the logic it is programmed with. Traffic information at its most basic is a simple incident report. More complex traffic information is also able to incorporate historical and congestion information.
The key to good traffic applications is good traffic data. This means not just where a traffic incident has taken place, but how it has impacted the surrounding road network. Traffic data providers collect information through road sensors, inductive loops, and floating car data (FCD). Road sensors and inductive loops are fixed-speed measurement devices in the road network. FCD, on the other hand, is captured by vehicles equipped with speed sensors driving in traffic. These collection systems report information via mobile networks on traffic incidents and traffic flow (average speed). The best data providers, such as DDG in Germany, aggregate various disparate sources and normalize the data before providing a traffic feed. This process can be seen in Figure 11.2.
Figure 11.2. DDG Traffic Collection and Processing. 2001 DDG Gesellschaft f ¼r Verkehrsdaten mbH.
Data processing after collection includes building traffic models, coding reports from various sources to one standard format, and producing data forecasts based on current conditions. Traffic reporting is one of the least standardized areas of mobile location services, with many local providers using proprietary formats. As shown in Figure 11.3, DDG processes many different traffic data sources, some proprietary and owned by DDG and other public and broadcast by radio or even sent by fax.
Figure 11.3. Traffic Data Normalization Process. 2001 DDG Gesellschaft f ¼r Verkehrsdaten mbH.
Traffic reports that are incident based provide information on where an accident occurred, but give no information on what impact it has had on the surrounding road network, if any. This type of traffic information is typical of U.S.-based incident reports, because the vast road network makes coverage with induction loops and road sensors that capture flow information a very expensive proposition. It is challenging to use incident-based traffic information to build a dynamic navigation system, because an incident could have little impact on driving conditions. Without congestion information such as real-time access to average road speed, deciding whether to route someone around an incident is primarily guesswork.
Historical and Congestion-Based Traffic
To make dynamic navigation solutions really work requires the ability to know the real-time impact on the road network of a traffic incident. This is usually measured by average speed and is calculated using induction loops or road sensors. In Europe, traffic information aggregators such as Trafficmaster and DDG have developed large networks with good coverage for the major motorways. It is possible to add FCD to congestion-based traffic information to develop historical traffic models. FCD allows traffic providers to drive areas where they don't have sensors, and using GPS and speed sensors, capture road speed information at specific intervals to build a historical model for predicting future conditions. Unlike real-time traffic information, which is only valuable for current condition queries, historical traffic information can be taken into account for very long trips and when a future trip is planned. A user planning a trip that takes several days would have anticipated traffic conditions considered in his or her route. If planning a future trip, alternate travel times could be suggested to a user if anticipated traffic conditions might make a journey longer at the time requested .
Product Integration and Use in LBS
Linking Traffic to Maps
To be able to use real-time traffic information in mobile location service applications requires embedding traffic location IDs in maps as attributes of road links or providing translation tables to convert traffic locations to a map vendor's internal road link or location IDs. In Europe, traffic incidents are usually keyed to Radio Data Services “Traffic Message Channel (RDS “TMC) codes that have been established by the European Union to allow traffic information to be accurately delivered by FM radio. An exchange protocol named ALERT-C has been recommended as a standard method for exchanging traffic information throughout Europe. The development of comparable traffic standards in North America is in the very preliminary stages, although map data vendors such as Navigation Technologies have included a coding similar to European-style TMC codes in their North American maps.