US20090287405A1

US20090287405A1 - Traffic data quality

Info

Publication number: US20090287405A1
Application number: US12/272,466
Authority: US
Inventors: Kungwel Liu; Susan S. Chen; Merlin J. Smith
Original assignee: Garmin Ltd Kayman
Current assignee: Garmin Ltd Kayman
Priority date: 2008-05-15
Filing date: 2008-11-17
Publication date: 2009-11-19
Also published as: EP2286399A4; CN102113037A; EP2286399A2; WO2009139979A3; WO2009139979A2; US8855899B2; EP2286400A1; CN102027523B; CN102027523A; EP2286400A4; WO2009139980A1; US20090287402A1

Abstract

Techniques are described for traffic data quality. In an implementation, an electronic device provides a variety of functionality including functionality to determine position. The device may use determined position to ascertain geographic locations as collection points where traffic related data may be collected. In at least some embodiments, traffic data quality techniques combining both device side and server side technique are applied to data collected at the collections points. In an embodiment, communication of collected data by the device may be delayed to enable additional observations of vehicle movement, routing, position, and so forth. The additional observations during the delay enable the device to determine the validity of the collected data.

Description

RELATED APPLICATIONS

This Application, under the provisions of 35 U.SC. §119(e), claims the benefit of priority to U.S. Provisional Application Ser. No. 61/053,306, filed May 15, 2008, entitled “Traffic System” the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

Traditional traffic solutions involve aggregating traffic information from various sources that rely on costly deployment and monitoring of road side sensors, dedicated traffic reporters, often in helicopters, or police units responding to accidents. Also, the process of aggregating traffic information from such wide variety of sources relies heavily on humans which are proven error-prone. Another type of traffic solution involves collecting historical traffic data and providing statistical travel speed for route planning. Historical data analysis provides a good approximation about what the traffic condition should look like. However, it lacks timely feedback of what's happening in real-time. This solution also relies heavily on accurate and complete sources of historical data.
The term floating car data has been used to generally refer to data collected by way of user devices such as phones, pda's, laptop's and other suitably configured devices that may be used to track aspects of a vehicle in which the device is located. Although floating car data has the potential of being a source of highly precise traffic data, floating cars typically are not driven for the purpose of collecting traffic information. The floating cars are driven by “real” people who may be commuting to work, stopping for a stop sign/light, picking up friend, and so forth. Often these “real” people may slow-down or stop for non-traffic related reasons, such as stop by a coffee shop or gas station, slowing down to find a street or address, running an errand on the way to work, and so forth. Traditional technique for collection of traffic data may not account for such non-traffic related slow-downs or stops. Accordingly, the traffic data collected by these traditional techniques may be inaccurate.

SUMMARY

Techniques are described for traffic data quality. In an implementation, an electronic device provides a variety of functionality including functionality to determine position. The device may use determined position to ascertain geographic locations as collection points where traffic related data may be collected. In at least some embodiments, traffic data quality techniques both device side and/or server side technique are applied to data collected at the collections points. In an embodiment, communication of collected data by the device may be delayed to enable additional observations of vehicle movement, routing, position, and so forth. The additional observations during the delay enable the device to determine the validity of the collected data. In another embodiment, the collection points may be particularly arranged to promote data quality. For example, collection points may be arranged such that each road segment joined at an intersection has at least two collections points.
This Summary is provided solely to introduce subject matter that is fully described in the Detailed Description and Drawings. Accordingly, the Summary should not be considered to describe essential features nor be used to determine scope of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items.

FIG. 1 depicts an exemplary environment in which traffic data quality techniques may be employed.

FIG. 2 depicts an exemplary implementation of a device to perform traffic data quality techniques.

FIG. 3 is a flow diagram depicting an exemplary procedure in accordance with one or more embodiments.

FIG. 4 is a flow diagram depicting an exemplary procedure in accordance with one or more embodiments.

FIG. 5 depicts a system in which traffic data quality techniques may be employed.

FIG. 6 is a flow diagram depicting an exemplary procedure in accordance with one or more embodiments.

FIG. 7 is a flow diagram depicting an exemplary procedure in accordance with one or more embodiments.

FIG. 8 depicts an exemplary implementation of an arrangement of virtual traffic sensors.

DETAILED DESCRIPTION

Exemplary Environment

A FIG. 1 illustrates an implementation of an environment 100 in which techniques for traffic data quality may be employed. In the following discussion, aspects of traffic data quality techniques are described in the context of a traffic system that employs virtual traffic sensors to collect traffic data. It is noted however that the techniques to improve traffic data quality may be employed with a wide variety of traffic data collection techniques. The term floating car data has been used to generally refer to data collected by way of user devices such as phones, pda's, laptop's and other suitably configured devices that may be used to track aspects of a vehicle in which the device is located. It is contemplated that the traffic data quality techniques described herein may be generally applicable to traffic data that is collected using various floating car techniques and devices. The inventive virtual traffic sensors techniques are described below to provide the reader with a tangible example of but one floating car data collection technique to which the described traffic data quality techniques may be applied.
In the depicted example, the environment 100 includes an electronic device 102. Electronic device 102 may be configured to provide a variety of functionality through various applications, components, modules, and operational modes of the electronic device 102. A variety of electronic devices 102 suitable to provide the variety of functionality are contemplated. For instance, an electronic device 102 may be configured as devices including, but not limited to: a mobile phone; a portable navigation device; a portable computer; a desktop computer; a personal digital assistant; a multimedia device; a game device; and/or combinations thereof. In the following description a referenced component, such as electronic device 102, may refer to one or more entities, and therefore by convention reference may be made to a single entity (e.g., the electronic device 102) or multiple entities (e.g., the electronic devices 102, the plurality of electronic devices 102, and so on) using the same reference number.
In an implementation, electronic device 102 includes functionality to determine position. For example, electronic device 102 is depicted as including a satellite navigation receiver 104 that represents functionality to receive signal data 106 from navigation satellites 108. Satellite navigation receiver 104 may be configured in a variety of ways such as a global positioning system (GPS) receiver, a GLONASS receiver, a Galileo receiver, or other satellite navigation receiver. Additionally or alternatively, the electronic device 102 may determine position using other methods, as is discussed in more detail below.
Electronic device 102 also includes a communication module 110 representative of communication functionality to permit electronic device 102 to send/receive data between different devices (e.g., components/peripherals) and/or over the one or more networks 112. Communication module 110 is representative of a variety communication components and functionality including, but not limited to: one or more antennas; a browser; a transmitter; a receiver; a wireless radio; data ports; software interfaces and drivers; networking interfaces; data processing components; and so forth.
The one or more networks 112 are representative of a variety of different communication pathways and network connections which may be employed, individually or in combination, to communicate among the components of the environment 100. Thus, the one or more networks 112 may be representative of communication pathways achieved using a single network or multiple networks. Further, the one or more networks 112 are representative of a variety of different types of networks and connections including but not limited to: the Internet; an intranet; a satellite network; a cellular network; a mobile data network; wired and/or wireless connections; a radio broadcast network; and so forth. Examples of wireless networks include but are not limited to networks configured for communications according to: one or more standard of the Institute of Electrical and Electronics Engineers (IEEE), such as 802.11 or 802.16 (Wi-Max) standards; Wi-Fi standards promulgated by the Wi-Fi Alliance; Bluetooth standards promulgated by the Bluetooth Special Interest Group; and so on. Wired communications are also contemplated such as through universal serial bus (USB), Ethernet, serial connections, and so forth.
For example, electronic device 102 (through functionality represented by the communication module 110) may be configured to communicate via one or more networks 112 with one or more service providers 114. FIG. 1 depicts an example service provider 114 that may include a service manager module 116 operable to manage and provide a variety of services 118(k), where k may be any integer from 1 to “K”. The example service provider 114 also includes a data store 120 that is representative of storage capacity that may be used to store a variety of service data 122 related the services 118(k).
Service manager module 116 is representative of functionality to configure services 118(k), manage access to services 118(k), provide services 118(k) over a network 112, and so forth. Service manager module 116 may also implement server side data quality techniques described in more detail in relation to FIG. 6-7 below. Multiple services 118(k) may be provided by a single service provider 114. Further, electronic device 102 may access multiple services providers 114 each configured to provide a different set of services 118(k) via the one or more networks 112. By way of example and not limitation, services 118(k) provided by one or more service providers are illustrated as including Internet 118(1) service, phone 118(2) service, traffic 118(3) service, and position 118(4) service.
Internet 118(1) service is representative of a variety of different types of Internet content and/or services, examples of which include but are not limited to web pages, location services, web services, music, video, email service, instant messaging, and so forth. Phone 118(2) service is representative of mobile phone and/or data services that may be provided by one or more service providers 114, such as by a cellular provider over a cellular network. Traffic 118(3) service may include traffic updates/alerts, routing and re-routing, delay notification, and so forth.
As described above and below, traffic 118(3) service may be provided, at least in part, based upon data collected by electronic device 102 using one or more virtual traffic sensors (VTS). VTS are logically defined locations that are used to indicate when and/or where an electronic device 102 may collect traffic related data. The VTS may represent logical abstractions of geographic locations. Thus, each virtual traffic sensor (VTS) is a logical sensor whose location, in relation to the currently traveled road segment, is determined by a set of VTS criteria. Flexible and strategic location of virtual traffic sensors according to VTS criteria can enable reduced data storage and communication cost for collection of traffic related data while maintaining good data quality. A variety of VTS criteria to locate VTS are contemplated, further discussion of which may be found in relation to the following figures. Traffic related data may be collected at or near locations of each virtual traffic sensor. The collected traffic related data may be communicated back to a central location (e.g., a service provider 114), where the collected data may be analyzed, stored, formatted, and/or otherwise manipulated to facilitate provision of traffic 118(3) service by one or more service providers 114. For instance, traffic related data may be stored in a data store 120 of a service provider 114 as service data 122.
Position 118(4) service is representative of position determining functionality that may be provided as a service from a service provider 114. Electronic device 102 may be configured to determine position via position 118(4) service in addition to or in lieu of determining position by way of signal data 106 received via a satellite navigation receiver 104 of the device. A variety of other 118(5) services that may be provided by way of one or more service providers 114 are also contemplated, examples of which include but are not limited to: radio data service, audio/video service, messaging service, and weather service.
As noted, electronic device 102 may be configured to determine position. More particularly, electronic device 102 may include a position module 124 that is configured to manage, use, and selectively switch between a variety of position sources and/or position-determining techniques to determine a geographic position of the electronic device 102. For instance, position module 124 may manage and process signal data 106 received from the navigation satellites 108 via the satellite navigation receiver 104. The electronic device 102 may receive signal data 106 transmitted by one or more position data platforms and/or position data transmitters, examples of which are the depicted as the navigation satellites 108. The position module 124 is representative of functionality operable to determine a geographic position through processing of the received signal data 106. The signal data 106 may include various data suitable for use in position determination, such as timing signals, ranging signals, ephemerides, almanacs, and so forth. Thus, position module may manage and process signal data 106 from navigation satellites 108 to provide a variety of position-determining functionality. In an embodiment, the satellite navigation receiver 104 is a Global Positioning Satellite (GPS) receiver operable to receive signal data 106 from navigation satellites 108 that are configured as GPS satellites in a GPS system.
In addition to determining position through the satellite navigation system as described, it should be apparent that a wide variety of other positioning systems may also be employed, such as terrestrial based systems (e.g., wireless-phone based systems that broadcast position data from cellular towers, such as through phone 118(2) service), wireless networks that transmit positioning signals, and so on. Any suitable position determining techniques may be employed. For example, positioning-determining functionality may be implemented through use of a server in a server-based architecture, from a ground-based infrastructure, through one or more sensors (e.g., gyros, odometers, and magnetometers), use of “dead reckoning” techniques, and so on. The position module 124 may also be configured to selectively switch between a variety of position-determining techniques that may be available through different position sources. Thus, in addition to using the navigation satellites 108, the position module 124 may also be configured to determine position by way of one or more service providers 114, such as determining position through Internet 118(1) service, phone 118(2) service, and/or position 118(4) service.
The electronic device 102 may include a variety of device applications 126 which may be configured to provide a wide range of functionality to the electronic device 102. The position module 124 may be operable to provide a determined position and/or other position data to the various device applications 126 to enable position dependent functionality. Position dependent functionality may include but is not limited to: indicating geographic position on a map; tracking speed and distance; weather service; traffic service; providing navigation instructions; providing trip data; conducting position based point of interest (POI) searches, database searches, and/or Internet searches; and so forth.
The electronic device 102 may also include a device application 126 that is configured as a traffic module 128. The traffic module 128 is representative of various traffic related functionality that may be provided by an electronic device 102. For instance, traffic module 128 may be configured to receive traffic 118(3) service from one or more service providers 114. Further, traffic module 128 may be configured to collect various traffic related data and/or to cause communication of the collected traffic related data to the one or more service providers 114. Traffic module 128 may also implement device side data quality techniques described in more detail in relation to FIG. 6-8 below.
In one or more embodiments, traffic module 128 may also operate to ascertain locations for collection points where the electronic device 102 collects traffic related data. In at least some embodiments, the collection points are logically defined virtual traffic sensors (VTS) that are associated with geographic locations. For example, traffic module 128 may use VTS data 130 to ascertain locations for virtual traffic sensors (VTS). Traffic module 128 is further operable to collect traffic data when in proximity to the VTS. In one or more embodiments, traffic module 128 may maintain a traffic log 132. When a suitable connection is available, such as connection by way of communication module 110 over the network 112 to service provider 114, traffic module 128 may cause communication of the traffic log 132 to the service provider 114. In other embodiments, communication of traffic related data may occur substantially in real-time, e.g., contemporaneously with (within a few minutes of) collection of the data. Further discussion of virtual traffic sensors to enable traffic related functionality of an electronic device 102 may be found in relation to the following figures.
FIG. 2 depicts an implementation 200 of an example of electronic device 102 of FIG. 1 in greater detail. In particular, an example electronic device 202 configured as a portable navigation device (PND) is illustrated. The example electronic device 202 of FIG. 2 is illustrated as including a processor 204 and memory 206 that may be utilized to provide a variety of processing and storage capabilities.
Processor 204 is not limited by the materials from which it is formed or the processing mechanisms employed therein, and as such, may be implemented via semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)), and so forth. Additionally, although a single memory 206 is shown for the electronic device 202, a wide variety of types and combinations of memory may be employed, such as random access memory (RAM), hard disk memory, removable medium memory (e.g., the memory 206 may be implemented via a slot that accepts a removable memory cartridge), and other types of computer-readable media capable of storing data and program code executable by one or more processors.
In the example electronic device 202 of FIG. 2, the position module 124, communication module 110, and traffic module 128 are illustrated as modules that are executed via processor 204 and are also storable in the memory 206. It is noted generally that any of the functions described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “functionality” as used herein generally represent software, firmware, hardware or a combination thereof. In the case of a software implementation, for instance, the module represents executable instructions that perform specified tasks when executed on a processor, such as the processor 204 with the electronic device 202 of FIG. 2. The program code can be stored in one or more computer-readable storage media, an example of which is the memory 206 associated with the electronic device 202 of FIG. 2.
The electronic device 202 may establish communication connections to service providers 114, such as a connection to a server of the service provider 114. Through execution of service manager module 116, service provider 114 may provide a variety of services 118(k) over a network 112 to the electronic device 102. The example service provider 114 of FIG. 2 is illustrated as configured to provide at least traffic 118(3) service. Service provider 114 through service manager module 116 may also maintain a traffic database 208. Traffic database 208 is representative of a portion of memory (e.g., data store 120 of FIG. 1) of a server corresponding to a service provider 114 that is arranged to store traffic related data. Examples of traffic related data that may be stored in traffic database 208 include but are not limited to: raw data from devices that is used for substantially real time provision of traffic service 208; historical traffic data that can be manipulated in various ways to identify traffic trends and patterns; traffic logs 132 collected from devices; and so forth.
The memory 206 of electronic device 202 is illustrated a storing various device applications 126, signal data 106 that may be received via the satellite navigation receiver 104, VTS data 130, and traffic log 132. The device application 126 are illustrated as including a browser 210, a phone 212 application, and a navigation 214 application. The browser 210 represents functionality executable on the processor 204 to interact with Internet 118(1) service from a service provider 114 configured as an internet provider, such as to obtain email service, send/receive instant messaging, view web pages, download video programs or other content, obtain traffic 118(3) service, and so forth. Phone 212 application represents functionality executable on the processor 204 to obtain phone 118(2) service from a service provider 114 configured as a cellular provider, such as to make and receive mobile phone calls, manage contacts, create/send/receive text messages, access Internet content over cellular, and so on.
Navigation 214 application represents functionality executable on the processor 204 to provide a variety of navigation functionality. For example, the navigation 214 application may be configured for outdoor navigation, pedestrian navigation; vehicle navigation, aerial navigation (e.g., for airplanes, helicopters), marine navigation, personal use (e.g., as a part of fitness-related equipment), and so forth. The navigation 214 application for instance, may be executed to use signal data 106 received via a GPS receiver to generate navigation instructions (e.g., turn-by-turn instructions to an input destination), show a current position on a map, and so on. The navigation 214 application may also be executed to provide other navigation functionality, such as to determine a current speed, calculate an arrival time, and so on. Further, navigation 214 application may utilize traffic related data received through operation of the traffic module 128 for the purposes of route planning, re-routing, output of traffic notifications, enhanced calculation of arrival times, and so forth.
A variety of other 216 applications may also be included to provide additional functionality to the electronic device 202. Examples of other 216 applications may include but are not limited to: media applications, games, database, productivity suite, an operating system, drivers, desktop applications, device specific applications, and so forth. Thus, device applications 126 represent a wide variety of functionality that may be operable on the example electronic device 202.
Electronic device 202 is further illustrated as including a position database 218. Position database 218 is representative of a variety of data that may be maintained locally on an electronic device 202 to enable various position-determining techniques and/or navigation functionality. Examples of data that may be maintained in a position database 220 include but are not limited to: position data 220, point of interest (POI) data 222, and map data 224. A variety of other data 226 is also contemplated. Position data 220 is representative of various cached position data such as: cached signal data 106; historical position data; routes and patterns; position source selection criteria, and so forth.
POI data 222 represents data describing various places such as businesses, offices, parks, and so forth that users of the electronic device 202 may be interested in, e.g., points of interest (POIs). POI data 222 may be used to locate various types of POIs, such as through displaying hotels, restaurants, fuel, ATMs, and so forth on a map and/or providing instructions to navigate to various POIs. In an embodiment, virtual traffic sensor (VTS) may be configured as POI's having particular characteristics and functions. That is, proximity to POIs defined as VTS may trigger collection and/or communication of traffic related data. In this embodiment, VTS may be implemented through adaptation of existing POI databases to include VTS locations as POIs.
Map data 224 represents various types of maps (e.g., road, topographic, hybrid, satellite) and related data that may be used by electronic device 202 to provide various position-determining techniques and/or navigation functionality, such as showing position on a map, calculating turn-by-turn navigation instructions, display of POIs, and so on. Map data 224 may also be used by traffic module 128 to ascertain locations for VTS. For instance, a determined position along with map data 224 may be used to understand characteristics of roads along a route, such intersection locations, road class, and so forth.
Traffic module 128 may use the road characteristics along with other VTS criteria to locate one or more VTS locations along the route. As noted, VTS data 130 may include various VTS criteria that may be employed to locate VTS, further discussion of which may be found in relation to the following figures. VTS data 130 may also include pre-defined VTS locations (recommended and/or default locations) that may be defined by a service provider 114. Electronic device 202 may be pre-loaded with a set of pre-defined VTS that are updatable over a network 112, such as via service provider 114. In at least some embodiments, a particular arrangement of VTS may be specified through the VTS data 130, such that each road segment between intersections includes at least two virtual traffic sensors. Further discussion of defining a particular arrangement for VTS may be found in relation to FIG. 8 below.
Traffic module 128 may use the pre-defined VTS location directly. Additionally or alternatively, traffic module 128 may be operable to define its own VTS locations based upon the VTS criteria, alone or in conjunction with the pre-defined VTS locations. Then, a determined position may be used to detect proximity to the VTS locations. When proximity to a VTS location is detected, traffic module 128 operates to collect various traffic related data. Traffic related data may be communicated substantially in real-time to a service provider 114, when a suitable connection is available. Additionally or alternatively, traffic related data may be stored as a traffic log 132 and communicated at a later time, such as when a suitable connection is available. A variety of other examples are also contemplated.
While position database 218 is illustrated as stored locally on electronic device 202, it is contemplated that portions of the data may be maintained in a remote storage location, such as being maintained by a service provider 114 configured to provide the data as a service. The electronic device 202 may interact with the remote storage location to perform updates of data maintained locally in the position database 220. Updating may also include updating VTS data 130, such as updating pre-defined locations for VTS and/or VTS criteria. In addition to or in lieu of maintaining data locally in a position database 220, electronic device 202 may use portions of the data represented by position database 220 directly from a remote storage location, e.g., without maintaining the data in local storage. Further discussion of these and other features of virtual traffic sensor techniques may be found in relation to the following procedures.

Exemplary Procedures

The following discussion describes example techniques for data collection and data quality that may be implemented utilizing the previously described systems and devices. By way of example, some of the following techniques are described in the context of data collection by way of virtual traffic sensors as described above and below. It is again noted, that a variety of other data collection techniques (e.g., floating car data techniques) to which traffic data quality techniques may be suitably applied are contemplated. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference may be made to the environment 100 of FIG. 1 and the example devices of FIG. 2. The features of techniques described below are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

Data Collection Examples

FIG. 3 depicts a procedure 300 in an exemplary implementation in which a electronic device, such as a portable navigation device, employs virtual traffic sensors (VTS) to collect traffic related data. Locations for one or more virtual traffic sensors are ascertained (block 302). For instance, a traffic module 128 of an electronic device 102 can be configured to ascertain locations for VTS along a travel route. One way this may occur is by storing locations for VTS in a database on the electronic device 102. For example, VTS data 130 may include a database of locations of virtual traffic sensors. VTS data 130 can also include various criteria that may be employed to arrive at locations for VTS. The locations of VTS may include either or both of pre-defined locations that are provided by a service provider 114, initially provided by the manufacturer of the electronic device 102, and/or locations that are determined by way of the traffic module 128 at an electronic device 102 according to the various criteria. Data related to traffic conditions is collected at or near each virtual traffic sensor location. Strategic placement of virtual traffic sensors may reduce data storage and transportation cost while maintaining good coverage.
As the virtual traffic sensors (VTS) are logically defined locations, the data collection points are not constrained by the location of physical elements, such as communication infrastructure components, physical data collection components located along roadways, and so forth. Accordingly, cost associated with deployment may be reduced. Further, the sensor locations may be flexibly arranged and re-arranged with little associated time and/or cost. New VTS criteria and/or locations for VTS may be quickly defined and distributed to devices to change the arrangement of VTS.
In contrast, traditional techniques may rely upon fixed infrastructure for data collection points. Additionally, traditional techniques for traffic data collection may operate by feeding current traffic conditions from devices to a server at a periodic time interval. However, if the feedback is set too frequently, it may create redundant information and overload server resources, thereby increasing cost and potential failures. On the other hand, if time interval is set too long, critical situations may fall between intervals and therefore may be missed. Further, the time interval approach may not consider differing road characteristics or conditions, such as considering whether the road is in a city or out in the country. Accordingly, the frequency with which data is fed to the server may not be adjusted to account for the differing road characteristics or conditions.
By using configurable VTS criteria to strategically locate VTS, flexibility to arrange and re-arrange the locations is achieved. Moreover, the criteria used to select VTS locations may take into account a variety of factors to reduce communication of redundant or useless data, prevent overloading of devices and servers by over communication, and provide an adaptable system that can be adjusted easily and cost effectively.
A variety of criteria suitable to enable determination of locations for VTS are contemplated. VTS criteria may include, but are not limited to: (1) route characteristic criteria, (2) delay criteria, and (3) traffic trend criteria. Route characteristic criteria refer to characteristics related to a traveled or planned route and the roadways of the route. Route characteristics may be derived from map data 224 that is correlated to determined positions and/or to a planned route. Using the route characteristics, VTS may be strategically located in “high” traffic areas, for example around major intersections, along major thoroughfares, in city areas, and so forth. Relatively fewer VTS may be located in rural areas, on major highways along open stretches, and in other areas where traffic problems may occur infrequently. In this manner, resources of both devices and servers may be directed to obtaining quality traffic data in areas that are more likely to experience traffic problems. Examples of route characteristics include but are not limited to: distance to the coming intersection and/or between intersections; length of the currently traveled road segment; type of the upcoming intersection; road class; terrain of a traveled route (flat, mountainous); and so forth.
Delay criteria refer to factors from which travel time differences may be inferred. The number of VTS and/or locations for VTS may depend upon an expected travel time and delays for a route. For instance, more VTS may be defined for a route for which delays are expected so that accurate delay information can be obtained. Examples of delay criteria may include weather conditions (e.g., rain, snow); seasonal traffic differences (winter vs. summer); known traffic accidents or other incidents; constructions zones; special events (parades, sporting games, rock concerts), and so forth. Delay criteria may be used to dynamically locate VTS, such as adding VTS to a rural route when a accident occurs, locating a VTS at ingress and egress routes to a stadium at the time of a sporting event, and so forth.
Traffic trend criteria refer to a variety of historic traffic trends that may depend upon such items as the time of day, day of the week, calendar (e.g. holiday and seasonal traffic trends), and other items to which traffic trends may be associated. For example, fewer VTS may be located along a city route on a Saturday than on a Monday. Likewise on a route used by weekend travelers, more VTS may be located on a Friday afternoon than on a Friday morning. Thus, various traffic trend criteria may be employed to inform the determination of where to locate VTS.
Other VTS criteria are also contemplated. For instance, a system administrator may define various constraints designed to improve data quality. For example, a maximum travel time between virtual traffic sensors (VTS) may be defined. Thus, along rural routes VTS may be dynamically located so that traffic data is collected and/or reported at least every hour. Similarly, a maximum time to an upcoming VTS (e.g., an already determined VTS location) may be defined. When an electronic device 102 does not reach the upcoming VTS before the maximum time, a traffic incident or other delay may have occurred. Thus, the device may be configured to report and/or record traffic condition when the maximum time has been reached.
Various VTS criteria may be associated with different priorities and weight. The combination of the priorities and weight of these criteria may be used in the determination of the location of a VTS for a specific geographic area and/or route. As noted the VTS criteria can be parameterized and made configurable. Each electronic device 102 can be pre-loaded with VTS criteria and/or can receive the VTS criteria when the device connects to the central server. In an embodiment, VTS criteria are managed by the system administrator so they can be adapted as required. Since the central server (e.g., service provider 114) knows the location of each device when it is connected, the VTS criteria communicated to devices may be specific to geography. Thus, a set of VTS criteria communicated in New York City may be different than a set of VTS criteria communicated in Fargo or Seattle.
Position is determined using one or more position determining techniques (block 304). For instance, electronic device 102 may be configured to determine position using a plurality of position determining techniques as discussed previously. In an implementation, an electronic device 102 may use a satellite navigation receiver 104 to obtain signal data 106 from navigation satellites 108 that may be used to determine a position of the electronic device. An electronic device 102 may also obtain position via position 118(4) service from a service provider 114.
Proximity is detected to one or more VTS according to the determined position (block 306). For instance, an electronic device 102 may utilize a determined position to detect when the device is at or near to a VTS location. One way this may occur is through correlation of map data 224 with VTS data 130 that describes locations for VTS. A geographical location may be identified on a map based upon map data 224 and position determined through one or more position determining techniques. As noted, in one embodiment the VTS locations may be configured as a distinct type of points of interest (POIs) that are logically defined to control where traffic data is collected by suitably configured electronic devices 102. Thus, if an intersection of a main city thoroughfare is associated with a VTS, determined position may be used to determine proximity to the intersection and accordingly, proximity to the VTS. In particular, traffic module 128 may be configured to use determined position to monitor proximity to VTS and detect when the electronic device has arrived at the intersection and the corresponding VTS. A threshold value such as “within 50 meters”, “within 200 meters”, or “within 500 meters” may be configured to control how close a device is to a VTS when the traffic module 128 detects proximity to the VTS.
Traffic related data is collected when in proximity to the one or more virtual traffic sensors (block 308). For example, when proximity is detected, traffic module 128 may operate to trigger collection of various traffic data. The traffic module 128 may populate a variety of parameters and create a record that is associated with the particular VTS. Examples of parameters that may be collected at each VTS include but are not limited to: a VTS identifier, time, date, position information, map version data, vehicle identifier, subscriber/device identifier, and various traffic related parameters. By way of example and not limitation, traffic related parameters may include time intervals between VTS, device speed, device heading, road characteristics, vehicle route information, and so forth.
Collected traffic data is communicated to a service provider over a network (block 310). In an embodiment, a record of traffic data collected at a VTS location may be communicated substantially in real-time. For instance, if a network connection is available (e.g., WiFi, Cellular, etc.) then an electronic device 102 may be configured to communicate real-time traffic data back to a central collection point, such as to a service provider 114. Additionally or alternatively, electronic device 102 may maintain a traffic log 132 that may be communicated at a later time. For instance, the traffic log 132 may be maintained for communication when the device obtains a suitable network connection. In an embodiment, a small form factor device may obtain a suitable connection using another device, such as connecting a portable navigation device (PND) to a home computer and utilizing the capabilities of the home computer to communicate the traffic log 132 to the central collection point (e.g. a server of a service provider 114). The reported traffic condition may then be processed into useful format to provide a data source for real time traffic solutions and/or to facilitate provision of traffic 118(3) service to devices.
FIG. 4 depicts a procedure 400 in an exemplary implementation in which collected traffic related data is employed to provide traffic services. Criteria are defined for location of virtual traffic sensors (block 402). For example, service provider 114 may generate configurable VTS criteria that may be used to locate virtual traffic sensors. A variety of VTS criteria as discussed in relation to FIG. 3 may be defined. The VTS criteria may be dynamically configured to provide flexibility to adapt the traffic system to improve data quality or otherwise make adjustments.
The criteria are communicated to one or more devices (block 404). For instance, VTS criteria configured dynamically at a service provider 114 can be downloaded/updated when an electronic device 102 connects to a server of the service provider 114. VTS criteria may be stored locally at a device, for example as part of VTS data 130. Service provider 114 may also provide pre-defined VTS locations that may also be stored as VTS data 130.
Traffic data is received that is collected by the one or more devices at VTS locations designated according to the criteria (block 406). For example, electronic devices 102 may utilize VTS data 130 to locate VTS. The devices then collect traffic related data based upon the location of the VTS. Data may be collected by way of a traffic module 128 that detects proximity to VTS and generates a data record corresponding to the VTS. A variety of data may be collected at each VTS as discussed in relation to FIG. 3. The traffic module 128 may communicate the collected data to a service provider 114 as real-time data and/or as data that has been compiled into a traffic log 132.
Traffic conditions are determined based upon the received traffic data (block 408). Collected traffic data may be processed in a variety of ways to understand traffic conditions. For instance, collected traffic data may be analyzed to detect traffic incidents or other delays, calculate realistic travel times, and so forth. Collected traffic data may also be analyzed to identify trends, seasonal changes, alternate route options, and so forth.
Traffic services are provided to the one or more devices based upon the determined traffic conditions (block 410). For instance, traffic 118(3) service provided by one or more service providers may be based upon traffic data collected using VTS techniques described herein. For instance, traffic 118(3) service may include traffic updates, traffic alerts, routing and re-routing, delay notification, visual display of traffic conditions at an electronic device 102, route planning assistance, improved arrival time calculation, and so forth. In an implementation, a service provider 114 collecting the data may provide raw traffic data to various other providers who may process the data to determine traffic conditions. The collected data may be made available to numerous service providers 114 to enhance existing traffic solutions. Thus, data collected by logically defined VTS may be used by one or more service providers 114 to enable traffic services 118(3) to be provided.

System Architecture Example

FIG. 5 depicts an example traffic system generally at 500 that is suitable to employ one or more embodiments of traffic data quality techniques described herein. The traffic system 500 depicts example system architecture level components that may be implemented in software, hardware, or combinations thereof. The traffic system 500 is illustrated as including an example device 502, example server 504, and an example desktop 506 computing device. In one or more embodiments the device 502 may be communicatively coupled to the server 504 via a suitable network connection. In one or more other embodiments, the device 502 may be communicatively coupled to the server 504 by way of a suitable interface to the desktop 506. Thus, a device 502 may be configured to implement aspects of virtual traffic sensor techniques using both “onboard” (local resources/processing) and “offboard” (server-client resources/processing) resources in varying combinations.
A device 502 having substantially capabilities and resources (e.g., a mobile computing device) may establish a direct connection to the server 504, such as via a wireless network connection. Another device 502 having a small form factor may have relatively fewer capabilities and resources (e.g., a mobile phone). To improve performance, such a small form factor device 502 may be configured to offload processing tasks to the server side and/or may establish connections through an external device, such as using a wired (USB, serial, etc.) or wireless (Wifi, Bluetooth, etc.) connection to the example desktop computer 506 that has greater capabilities and network connectivity. A device 502 may also be configured to toggle between “onboard” and “offboard” in different situations, such as to optimize performance, manage resources (e.g., battery life and processor time), and so on.
Descriptions of each of the depicted architecture level components can be found in the following discussion. The traffic module 128 implements client-side functionality for traffic data quality techniques. Traffic module 128 may include functionality to determine locations for VTS as described herein. Further, traffic module 128 may operate to detect proximity to VTS, collect real-time traffic data based on VTS locations, maintain a traffic log 132, apply data quality techniques to collected traffic data, and cause communication of collected traffic data to service providers 114.
Communication module 110 as described in relation to FIG. 1 is also illustrated as being implemented as a component of device 502. Communication module 110 may include a connection daemon 508. Connection daemon 508 component is representative of functionality for detecting when a device has a suitable data connection to networks 112, servers, and/or service providers 114. For instance, the connection daemon 508 may detect a WiFi or another suitable network connection. Device 502 may also implement an autorun process 510. When a device 502 has a suitable network connection 112, the autorun process 510 may be invoked to automatically upload traffic log 132 and/or other data to the traffic server, e.g., to a service provider 114. Autorun process 510 may be implemented in a variety of ways such as being a standalone component, a component of the traffic module 128, and so forth.
Server 504 may include a presentation layer 512. The presentation layer 512 is representative of functionality operable to output interfaces that may be used to interact with the traffic system and traffic related data. For instance, an administrator may utilize features of the presentation layer 512 to configure aspects of the traffic system, perform analysis, manipulate traffic data, troubleshoot problems, and so on. Examples of interfaces that may be output via the presentation layer include a triage page 514 and a query page 516. Triage Page 514 may be output to display internal statistics, history of activities, and database states to help troubleshooting or “triaging” issues that may arise in the traffic system 500. Query Page 516 may be output to provide various data manipulation to support various triage situations. The administrator may perform various data queries through query pages 516, such as retrieving historic data, monitoring device connections, examining system attributes, viewing data logs, and so forth.
Server 504 may also include an application layer 518. The service manger module 116 of a service provider 114 may be implemented in the application layer 516. A variety of modules to provide traffic 118(3) service and aspects of traffic data quality techniques described herein may be implemented as sub-components of the service manager module 116. For instance, in the example of FIG. 5, service manager module 116 includes a data receiver module 520, a log receiver module 522, a configuration module 524, an authentication module 526, a traffic coder module 528, and an analytics module 530.
Data receiver module 520 is representative of functionality operable to receive and/or process real time data from a plurality of devices 502. In particular, data receiver module 520 may receive data that is communicated from devices 502 when the devices 502 detect proximity to VTS. Data receiver module 520 may receive datagrams from the devices 502 containing real time traffic data, manipulate the data, and store the data to a database. The data may then be made accessible for use by various entities, one of example of which is making the data accessible to one or more services providers 114 to facilitate provision of traffic 118(3) service.
Log receiver module 522 is representative of functionality operable to receive and/or process traffic logs 132 communicated from devices 502. Log receiver module 522 may save the log data into a database for further processing, such as to generate historical traffic data and trends. Log receiver module 522 may also convert traffic logs 132 into a suitable format, parse the logs 132, or otherwise manipulate the traffic logs 132 for storage and/or further processing.
Configuration module 524 is representative of functionality operable to make adjustments to update settings, change parameters, fine tune VTS criteria and/or locations, update settings for devices 502, and otherwise configure the components of the traffic system. Configuration module 524 enables the traffic system to be flexible in a variety of ways. Configuration module 524 may provide an administrator various configurable options to adjust the traffic system. Configuration module 524 may also enable control of system behavior at run time. For instance, each time a device 502 is connected to the server 504, the device may interact with the configuration module 524 to identify and obtain available updates. Configuration module 524 provides functionality to download configuration parameters, VTS criteria, VTS locations, and associated values to the devices. For instance, configuration module 524 may be configured by an administrator with updates to VTS criteria or VTS locations that may then be populated to the devices 502 when the devices 502 connect to the server 504 and interact with configuration module 524.
Authentication module 526 is representative of functionality to authenticate devices 502 to manage access to services 118(k), verify identity of devices 502, exclude unauthorized devices and/or or subscribers, and otherwise determine authorizations to access services 118(k), upload traffic data, and so forth. A variety of suitable authentication techniques are contemplated. Authentication module 526 may communicate with a subscriber database to determine which devices 502 are authorized and to which services 118(k) the devices 502 are given access. Authentication module 526 may also implement functionality to track interaction with traffic services 118(3), traffic data, and/or other services 118(k) on a device and/or subscriber basis.
Traffic coder module 528 represents functionality to code received traffic data into a standard format for distribution to devices 502 and subscribers. One example format is a format compatible with Traffic Message Channel (TMC) technology. In this example, traffic coder may code traffic data in accordance with TMC protocols. This may involve parsing of the traffic data into traffic event codes that are associated with location codes. The event/location combinations may be communicated to devices as part of traffic 118(3) service. One way this may occur is through FM broadcasts that includes the coded TMC data. To assign location codes to traffic events, traffic coder module 528 may utilize a location code table that relates position data included in the traffic data to the standardized location codes. While TMC coding is discussed by way of example, traffic coder module 528 may be configured to code traffic data into a variety of suitable standardized formats.
Analytics module 530 is representative of a variety of functionality to manipulate, analyze, and otherwise process traffic data that is collected from various devices 502. The analytics module 530 may operate to generate reports, traffic alerts, and so forth based upon analysis of collected traffic data. Analytics module 530 may also implement server side techniques to improve quality of collected traffic data. For instance, analytics module 530 may make comparisons of collected data from multiple devices to identify outlying data. Further discussion of techniques that may be implemented by analytics module 530 to improve data quality may be found in relation to the following figures.
Analytics module 530 may also determine optimal routing and re-routing based upon analysis of collected traffic data. Further, the analytics module 530 may perform historical processing tasks. For instance, analytics module 530 may periodically pull data from traffic log 132. Analytics module 530 may analyze the log data and calculate effective travel speed of various time slots, conditions, vehicle types, road classes, road segments, and so forth. The result of calculations performed by analytics module 530 may be persisted in a traffic database 208 that may be referenced to provide traffic 118(3) service to devices 502. Analysis of traffic data via analytics module 530 may also be used to adjust VTS locations and/or VTS criteria that may be used to determine VTS locations. While illustrated as a component of the service manager module 116, analytics module 530 may also be provided as a standalone module of the server 502, by way of a different server, either on-line or off-line, and so forth.
Components in persistence layer 532 are responsible for storing data and may support various queries to utilize and manipulate the data. Traffic database 208 may be implemented in the persistence layer 532 to store a variety of data related to virtual traffic sensor techniques. Some examples of such data include but are not limited to: real time data 534 that may be received by the data receiver module 520; historic traffic data 536 compiled through operation of the analytics module 530; traffic log data 538 from one or more devices 502 received via the log receiver module 522; and coded data 540 that may be generated through operation of the traffic coder module 528. Other examples of data that may be stored in traffic database 208 include VTS locations, criteria used to determine VTS locations, and other data that may be made available at server 504 to implement aspects of virtual traffic sensor techniques.
Components in desktop 506 are representative of functionality and interfaces to connect devices to the server 504 via desktop 506. Desktop 506 is illustrated as including a desktop daemon 542 and various browser plug-ins 544 to facilitate connection of a device 502 to the server 504. When connected through the desktop 506, a device 502 is able to interact with the server 504 and may offload various tasks to the desktop to improve performance. As noted a device 502 may also be configured to establish a direct connection to the server 504, e.g., without having to connect through the desktop 506.

Data Quality Examples

Having considered the foregoing example environment, devices, and techniques that may be employed to collect traffic related data, the following discussion is directed to example techniques that may be implemented to improve the quality of data that may be collected utilizing virtual traffic sensors and/or other floating car data collection techniques.
The traffic data quality techniques described herein may include data quality efforts from both device and server components. The various data quality efforts from both the device and server side may be combined to improve the quality of data that may be collected utilizing virtual traffic sensors and/or other floating car data collection techniques.
For instance, an electronic device 102 may obtain and/or store various data related to positions and motions of a vehicle, such as geographic position, velocity, vehicle parameters, points of interest, map data, and so forth. Thus, the electronic device 102 may include functionality operable to use the various data to make a determination of events (e.g., a slow down, stop, etc.) that occur for a particular vehicle. One way this may occur is through operation of the traffic module 128 previously described. The traffic module 128 may be further configured to correlate events using the various data to understand the nature of the event, in particular whether the event is traffic related or non-traffic related. For example, if traffic module 128 “knows” through route tracking and/or map data 224 that a vehicle made a right hand turn just before a stop and also “knows” through POI data 222 that a coffee shop is located at the place where the vehicle has stopped, the traffic module 128 may conclude that the stop is a non-traffic related stop. Action may then be taken to discard, flag, and/or otherwise manipulate collected data related to the non-traffic stop. This is one example of how device data may be employed to improve the quality of traffic data and traffic related service.
The electronic device 102 may not have information related to the “big picture” of what happened with all the other vehicles around. However, a server 504 of a service provider 114 configured to collect traffic data from multiple vehicles has information that may be used to understand the “big picture”. Thus, the server 504 may be able to “understand” the context in which data related to one vehicle was collected based upon data from multiple vehicles in the same geographic area. The server 504 may include functionality to compare data from multiple vehicles in the same area to improve traffic data quality. One way this may occur is through operation of the service manager module 116 and/or associated analytics module 530 as previously described. For example, given traffic data input from multiple vehicles in the same area, the analytics module 530 can be configured to recognize outliers such as a vehicle traveling in high speed on a high-occupancy vehicle (HOV) lane while regular lanes are jammed. The analytics module 530 can also be configured to recognize when one vehicle is fully stopped (e.g., on the road side or just off the road) while other vehicles are still moving. These and similar determinations enable the server 504 to associate traffic data communicated from electronic device with context in which the data was collected. The server 504 may use the context to remove data that doesn't make sense, e.g., outlying data, when performing analysis, providing traffic service, or otherwise manipulating the collected data. This is one example of how a server 504 may implement techniques to improve the quality of traffic data and traffic related services. Further discussion of various device side and server side techniques that may be used alone or in combination to improve traffic data quality can be found in relation to the following figures.
FIG. 6 depicts a procedure 600 in an exemplary implementation in which device side and server side quality techniques may be combined to improve the quality of collected traffic data. Traffic data is collected at a device (block 602). For example, virtual traffic sensors and techniques described herein may be defined and used by a traffic module 128 of an electronic device 102 to collect various traffic related data. A variety of other data collection techniques suitable to collect traffic related data from floating car sources are also contemplated. For example, physical sensors may be deployed to cause collection of traffic data by devices in various locations. In another example, a device may be configured to continuously or periodically collect traffic data without relying upon virtual or physical sensors. In yet another example, data collection may occur responsive to input from a user to cause collection of traffic data. For these example data collection techniques, as well as for variety of other suitable data collection techniques, data quality techniques described herein may be applied to improve the quality of the collected traffic data.
One or more data quality techniques are applied to improve quality of the collected traffic data (block 604). As depicted in FIG. 6, the one or more data quality techniques applied may combine application of both device side data quality techniques (block 606) and server side data quality techniques (block 608). One example of a device side data quality technique is the use of various vehicle position and motion data to identify and/or eliminate data that may describe or encompass non-traffic related events, as described above.
Another example of a device side data quality technique involves delayed reporting. With delayed reporting, collected data that would otherwise be communicated in substantially real-time may delayed to allow further observation of vehicle movement, route tracking, map data, position data, and so forth. In an embodiment, a relatively small delay period may be defined to enable a device to perform the additional observation and make a determination as to the validity of the collected data. The device may eliminate collected data that it determines to be invalid based on the additional observation. In one example, data may be considered invalid if the data encompasses non-traffic related events, such as the stops at a coffee shop, hotel, or other places of business. Further discussion of delayed reporting techniques that may be implemented by an electronic device 102 may be found below in reference to FIG. 7.
These and other device side techniques may be combined with various server side data quality techniques. As described above, one example of a server side data quality technique is the use of vehicle position and motion data from multiple vehicles/devices to identify and/or eliminate data that may describe or encompass non-traffic related events. Thus, a server may use the “big picture” to identify and/or eliminate outlying data. In another server side technique, a time limit may be associated with collected traffic data. Data that exceeds the time limit may be considered “stale”. Data that is considered “stale” may be handled in a variety of ways. For instance, the data may be eliminated from analysis that is performed to generate real-time traffic services. Data might also be stored as historical data in an archive and/or might be deleted. A server may also operate to flag or eliminate data from a device that it determines is malfunctioning. For example, a device or subscriber identifier may be associated with traffic log data that is sent to the server from a device. If outlying data or data that doesn't make sense is identified as having been received from a device, the associated device or subscriber identifier may be used to flag or eliminate other data from the device that might also be affected. This may include flagging data received during a configurable time period, eliminating some or all of the data received from the device, and so on. In this manner, data from suspect devices may be removed from analysis to improve the quality of stored traffic data and/or traffic services derived from the traffic data.
Another data quality technique involves the arrangement of collection locations where traffic data is collected. Generally, locations at which traffic data is collected using various floating car techniques may be defined to increase data quality. In one embodiment, when data collection is performed by way of previously described virtual traffic sensors (VTS), the VTS locations may be intelligently arranged to promote collection of high quality data. Further, the flexibility of VTS to be arranged and rearranged permits different configurations to be implemented quickly and cost effectively. Thus, multiple arrangements may be tried to compare the effects on data quality and arrive at a suitable arrangement. As discussed above, the arrangement of VTS may depend upon a variety of VTS criteria. Further, locations for VTS may be defined according to the criteria at either or both of the server and the device. Thus, intelligent arrangement of VTS locations may be considered as either or both of a device side data quality technique and/or a server side data quality technique. Further discussion of data quality techniques involving the strategic arrangement of collection locations may be found in relation to FIG. 8 below.
Traffic services are provided based upon the collected traffic data (block 610). In particular, quality data may be obtained from processing of collected traffic data through application of one or more data quality techniques described above. The processed data (e.g., quality data) may be used by a service provider 114 to configure traffic services 118(3). For instance, an analytics module 530 implemented as part of service manager module 116 may be operable to analyze the quality data in a variety of ways. For instance, analytics module 530 may use the processed traffic data (e.g., quality data) to calculate effective travel speed for various time slots, identify traffic incidents, initiate traffic alerts, calculate routings based on traffic conditions, and so forth. The result of calculations performed by analytics module 530 may be used to provide traffic 118(3) service to devices and/or may be persisted in a traffic database 208 for additional processing and/or reference.
FIG. 7 depicts an example procedure 700 in which an electronic device may employ delayed reporting to improve quality of traffic data collected by the electronic device. Delayed reporting techniques are described in which an electronic device 102 may hold collected data that would otherwise be communicated in substantially real-time (e.g., should-be-reported data) for a configurable delay period. The electronic device 102 may then observe a vehicle trace (e.g., observe vehicle motion, route, speed, position, heading, and so forth) for the duration of the delay. The electronic device 102 may use the additional data obtained through observation during the delay to make a determination as to validity of collected traffic data.
Referring now to procedure 700 of FIG. 7, traffic data is collected at a device (block 702). For example, an electronic device 102 may implement a traffic module 128 that is configured to collect traffic data using various techniques. For instance, traffic module 128 may be configured to collect traffic data at a plurality of virtual traffic sensor locations (VTS) as described above. Additionally or alternatively, traffic module 128 may configured to implement one or more other collection techniques suitable for collection of traffic data using floating car sources.
Reporting of collected traffic data is delayed to check data validity (704) and a determination as to validity of the collected traffic data is made (block 706). For the purpose of example, assume that an electronic device 102 is configured to communicate collected traffic data to a service provider 114 over a network 112. One way this may occur is through communication module 110 that provide a suitable network connection to one or more service providers 114, such as connection to a cellular data network and/or a wireless Internet connection. Accordingly, the electronic device 102, through operation of the communication module 110, may be capable of communicating traffic data substantially in real-time.
However, rather than communicate traffic data substantially in real-time, the electronic device 102 may be configured to implement delayed reporting techniques to improve data quality. In particular, traffic module 128 may provide functionality to make observations during a configurable delay period that may be used to ascertain validity of collected traffic data. In an embodiment, data that encompasses non-traffic related events may be considered invalid. Thus, traffic module 128 may be configured to distinguish between events (e.g., stops, slow downs, delays, turns, and so forth) that are traffic related and non-traffic related. To do so, traffic module 128 may use determined position and/or related position data 220 that may be provided by way of position module 124 to understand vehicle position, how fast a vehicle is moving, the direction of travel, recent turns, and so forth. The position data 220 may be correlated to POI data 222 and/or map data 224 to determine where a vehicle is located and/or what roads, stores and so forth are near to the location of the vehicle. The traffic module 128 may then ascertain from this information reasons why an event may have occurred.
By way of example and not limitation, reference is made to FIG. 8 to illustrate aspects of delayed reporting techniques that may be implemented by a suitably configured electronic device 102. FIG. 8 is a diagram 800 depicting an example arrangement of traffic data collection locations that may be employed in one or more embodiments. The diagram 800 includes example intersections 802 and 804. An example vehicle 806 is illustrated as travelling between the intersections 802, 804. FIG. 8 also depicts a plurality of collection locations 808(1)-808(8) in an example arrangement that is discussed in greater detail below. Another vehicle 810 is depicted that has stopped at a coffee shop 812 located alongside the road segment 814 between the intersections 802 and 804.
Both vehicles 806, 810 may include electronic devices 102 configured to collect traffic data when in proximity to collection locations 808(1)-808(8). Thus, at collection location 808(7) each vehicle collects traffic data by way of a respective electronic device 102. Vehicle 810 slows down just before collecting data at location 808(7) and then turns off the road and stops at the coffee shop 812. Thus, data collected by vehicle 810 may include data related to slowing down to stop at the coffee shop 812. After collecting data at location 808(7), vehicle 806 continues traveling along the road without stopping.
The electronic devices 102 travelling in vehicles 806, 810 may include a traffic module 128 configured to implement delayed reporting techniques. In particular, the traffic modules may cause data collected at collection point 808(7) to be held for a configurable delay period. During the delay period, traffic module 128 makes observations such as vehicle position, speed, direction and so forth. In an implementation, a trace of the vehicle in which an electronic device 102 is travelling (e.g., position data 220 describing vehicle positions, speed, direction, route and so forth) may be collected in a queue during the delay period. When the configurable delay period expires, the traffic module 128 may examine the vehicle trace information collected in the queue. Based at least in part upon the vehicle trace information, traffic module 128 may determine the validity of data that has been collected at collection point 808(7).
For instance, in the example of FIG. 8, vehicle trace data may be correlated to POI data 222 by traffic module 128 to identify that a coffee shop 812 is located near to where the vehicle 810 is stopped. Further, map data 224 correlated to the vehicle trace may indicate to the traffic module 128 that the vehicle 810 is off of the road way (e.g., in a parking lot). Thus, under these circumstances, traffic module 128 may conclude that the vehicle 810 has stopped at the coffee shop 812. Accordingly, traffic module 128 may consider the data surrounding the stop to be non-traffic related and may conclude that traffic data collected at collection point 808(7) is invalid. On the other hand, if map data 224 indicates that, based on vehicle trace and/or determined position, vehicle 806 is in the middle of the road, traffic module 128 may conclude that collected traffic data is valid.
As another example, the traffic module 128 may identify the validity of collected traffic data based on the path traveled by the vehicle 806. For instance, if the vehicle 806 slows down on a road to turn right onto a corner gas station, collected traffic data may incorrectly indicate a slowdown at VTS 808(1). By analyzing the vehicle trace information during the configurable delay period, the traffic module 128 can intelligently identify that the collected slowdown was due to a user stop, not traffic related.
Another example is when a vehicle 806 moves slowly in a parking lot parallel to a road and is very close to the road and a VTS position. Under such circumstances, it is not uncommon for a navigation device to recognize the vehicle as driving on the road passing the VTS. Instead of reporting the collected traffic data, embodiments of the present invention can detect, for example, that the vehicle 806 stopped with a heading perpendicular to the road (which indicates the vehicle stopped in a parking lot) or the vehicle turned perpendicular to road and quickly turned on the road (which indicates the vehicle left the parking lot).
Collected traffic data may be selectively communicated to a central collection location, e.g., service provider 114, based at least in part upon observations during the delay. Referring again to FIG. 7, when the collected data is determined to be valid based on the observations, the collected traffic data is communicated by the device to the service provider (block 708). Thus, in the case of vehicle 806 in the preceding examples, communication module 110 of electronic device 102 may operate to communicate data collected at collection point 808(7) to a service provider 114, following the delay period and validity determination. When the data is determined to be invalid, the device may discard the collected data (block 710). For instance, data collected by vehicle 810 in the preceding examples may be discarded based upon the determination that the stop at coffee shop 812 is non-traffic related and therefore the collected data is invalid. Alternatively, the collected data may be flagged as invalid so that it may be easily identified and/or removed from certain calculations and analysis. In this manner, the invalid data may still be collected for statistical purposes and/or to understand events that result in invalid data.
By way of example and not limitation, the following Table 1 provides one example of logic that may be used to implement delayed reporting at a electronic device 102 that uses virtual traffic sensors (VTS) to perform data collection:

TABLE 1

Traffic Data Collection Service with Delayed Report

Collection Routine

For each position, Do

Add position and speed to a queue, called Q

If Q does not have enough records (e.g. initial stage)

Continue to the next iteration

Determine “where am I” (in terms of which road segment, what kind

of road, where am I on the road segment related to previous and

next intersections, exits, or entrances, also check the time

and day against parameters)

If no need to report or record (e.g., position fix with low accuracy,

or on a residential street, based on configuration)

Continue to the next iteration

Determine where is the next virtual traffic sensor based on all the

parameters (CPU cycle can be saved if we can easily detect

same VTS calculated in the previous iteration is still ahead)

If current position is close to the VTS, or we have just passed it (in

the proximity of a VTS)

Do delayed_report

If result is DISCARD, continue to the next iteration

Else

Calculate ETA to the next VTS

If the ETA is too long

Do delayed_report

If result is DISCARD, continue to the next iteration

Else

Do Nothing

Delayed_Report Routine

Use Q to determine effective speed and position

Sleep for S seconds (configurable number of seconds)

Wake up and analyze entries in Q of the past S seconds

If user turned into a parking lot

Return DISCARD

If user stays in parking lot

Return DISCARD

If user fully stopped for X amount of time

Return DISCARD

If (more false cases can be added here)

Return DISCARD

Form the report using collected traffic data at VTS

If data connection is not available

Log speed, position and return DISCARD

Else

Send report to the traffic server

Return OK

Returning now to FIG. 8, the example arrangement of collection locations 808(1)-808(8) is discussed in greater detail. As noted, strategic placement of collection locations is one technique that may be employed to improve quality of data that may be collected from floating car sources. In an implementation, the collection locations 808(1)-808(8) depicted in FIG. 8 may be configured as virtual traffic sensors (VTS) that may be logically defined by a service provider 114 and or device 102 according to VTS criteria as previously described. Placement of a single collection location at each intersection may not provide suitable results. Such an arrangement may give mixed results due to traffic lights and their variable intervals controlled by departments of transportation (DOTs). Further, placing collection locations in the middle of a road segment may also not provide suitable data because traffic flow is generally the fastest in the middle of a road segment.
In an embodiment, two collections locations may be defined for each road segment between two adjacent major intersections. This provides an arrangement for collection locations 808(1)-808(8) as illustrated in the example of FIG. 8. In particular, along the central road segment 814 in FIG. 8, a collection location 808(1) is defined close to one entrance to intersection 802. This location may also be considered the exit to the road segment 814 (relative to the travel direction of vehicle 806). Another collection location 808(7) is defined on the central road segment 814 close to the intersection 804. This location may also be considered an exit from intersection 804 and the entrance to the road segment 814 (relative to the travel direction of vehicle 806). Likewise, collection locations 808(2)-808(4) are arranged around the intersection 802 close to the entrances to the intersection 802 from other directions. Additionally, collection locations 808(2)-808(4) are arranged around the intersection 804 close to entrances to the intersection 804 from other road segments. In this arrangement, traffic data is not captured in one snapshot. The traffic data throughout the whole of road segment 814 can be monitored by calculating the distance and time between three consecutive collection locations. For example, for vehicle 806 illustrated as travelling toward intersection 802, the traffic condition for the central road segment 814 may be captured using collection locations 808(7), 808(1) and one of 808(2)-808(4), depending upon what route vehicle 806 takes when exiting the intersection 802.
Arranging collection locations in this manner may provide finer resolution around each intersection. For instance, realistic turn cost between collection points 801(1) and each of 808(2)-808(4) may be captured. Further, realistic travel time between collection point 808(7) at an entrance to road segment 814 and collection point 808(1) at an exit to road segment 814 may also be captured. In the case of logically defined VTS locations, the described arrangement as in FIG. 8 may be specified for at least for some intersections by way of VTS criteria. For instance, VTS criteria may define the collection location arrangement of FIG. 8 for one or more classes of roads and/or intersections, e.g., relatively high traffic intersections and roads. Further, at other intersections, intersection types or classes, and/or at times having relatively low traffic flow, another arrangement might be specified according to the VTS criteria. Thus, a wide range of VTS arrangements including the arrangement of FIG. 8 may be employed for different roadways, intersections, time frames, road segments, classes, types of roads, and so on.

Conclusion

Various techniques for traffic data quality have been described. Although techniques for traffic data quality have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed devices and techniques for traffic data quality.

Claims

1. An electronic device comprising:

a processor;

memory coupled to the processor; the memory storing:

a position module operable via the processor to determine a position of the electronic device using one or more position determining techniques; and

a traffic module operable via the processor to:

collect traffic data for communication to a service provider based at least in part upon the position determined by the position module; and

determine validity of the traffic data and communicate valid traffic data to the service provider.

2. An electronic device as recited in claim 1, wherein the traffic module is further operable to delay communication of the traffic data to the service provider to enable the validity of the traffic data to be determined before communication with the service provider.

3. An electronic device as recited in claim 2, wherein the traffic module is further operable to:

observe a trace of a vehicle traveling with the electronic device during the delay; and

selectively communicate the collected traffic data to the service provider based upon the observed trace.

4. An electronic device as recited in claim 2, wherein the traffic module is further operable to:

determine validity of the traffic data during the delay;

when the traffic data is valid, cause communication of the traffic data to the service provider; and

when the traffic data is invalid, discard the traffic data.

5. An electronic device as recited in claim 2, wherein to determine validity of the traffic data during the delay comprises:

observing position of the electronic device as determined by the position module during the delay;

correlating the observed position to one or more of:

map data to calculate a trace followed by the electronic device;

point of interest data to identify one or more points of interest near the observed position; and

determining based upon the correlating whether the collected traffic data is valid as relating to a traffic condition.

6. An electronic device as recited in claim 1, wherein the electronic device is capable of communicating the collected traffic data in substantially real time.

7. An electronic device as recited in claim 1, further comprising a communication module to provide the collected traffic data over a network to the service provider.

8. An electronic device as recited in claim 1, wherein the device is configured to communicate the collected traffic data wirelessly from the device.

9. An electronic device as recited in claim 1, further comprising a receiver to receive signal data from a plurality of navigation satellites, wherein the position module is configured to use the signal data to determine the position of the electronic device.

10. An electronic device comprising:

a receiver to receive signal data from a plurality of navigation satellites;

a position module operable to determine position of the electronic device using the signal data; and

a traffic module operable to:

collect data for communication to a service provider;

delay communication of the collected traffic data to the service provider to enable a determination of validity of the collected traffic data; and

when the traffic data is valid, cause communication of the traffic data to the service provider,

wherein the determination of validity includes:

correlating the observed position to one or more of:

map data to calculate a trace followed by the electronic device;

11. An electronic device as recited in claim 10, further comprising a communication module to provide the collected traffic data over a network to the service provider.

12. An electronic device as recited in claim 10, wherein the device is configured to communicate the collected traffic data wirelessly from the device.

13. An electronic device as recited in claim 10, wherein the calculated trace indicates previous device positions, speeds, and directions.

14. An electronic device as recited in claim 10, wherein the traffic module is further operable to store collected traffic data in a traffic log for communication to the service provider.

15. A method comprising:

determining a position of an electronic device using one or more position determining techniques;

collecting traffic data for communication to a service provider using the electronic device based at least in part upon the determined position;

delaying communication of the traffic data to the service provider to enable a determination of validity of the traffic data.

16. A method as recited in claim 15, further comprising:

observing a trace of a vehicle traveling with the electronic device during the delay; and

selectively communicating the collected traffic data to the service provider based upon the observed trace.

17. A method as recited in claim 15, wherein the collected traffic data is communicated to the service provider in substantially real time.

18. A method as recited in claim 15, further comprising:

determining validity of the traffic data during the delay;

when the traffic data is valid, causing communication of the traffic data to the service provider; and

when the traffic data is invalid, discarding the traffic data.

19. A method as recited in claim 18, wherein the determination of validity of the traffic data during the delay comprises:

observing position of the electronic device;

correlating the observed position to one or more of:

map data to calculate a trace followed by the electronic device;

20. A method as recited in claim 19, wherein the calculated trace indicates previous device positions, speeds, and directions.

21. A method as recited in claim 15, wherein the traffic data is collected continuously.