US20070299602A1 - Rating that represents the status along a specified driving route - Google Patents

Rating that represents the status along a specified driving route Download PDF

Info

Publication number
US20070299602A1
US20070299602A1 US11/888,035 US88803507A US2007299602A1 US 20070299602 A1 US20070299602 A1 US 20070299602A1 US 88803507 A US88803507 A US 88803507A US 2007299602 A1 US2007299602 A1 US 2007299602A1
Authority
US
United States
Prior art keywords
route
travel time
magnet
delay
traffic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/888,035
Inventor
Gregory Auxer
James Carroll
Brian Smyth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Here Global BV
Original Assignee
Auxer Gregory A
Carroll James F
Smyth Brian J
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Auxer Gregory A, Carroll James F, Smyth Brian J filed Critical Auxer Gregory A
Priority to US11/888,035 priority Critical patent/US20070299602A1/en
Publication of US20070299602A1 publication Critical patent/US20070299602A1/en
Assigned to NAVTEQ B.V. reassignment NAVTEQ B.V. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: TRAFFIC.COM, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/01Detecting movement of traffic to be counted or controlled
    • G08G1/0104Measuring and analyzing of parameters relative to traffic conditions
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/36Input/output arrangements for on-board computers
    • G01C21/3691Retrieval, searching and output of information related to real-time traffic, weather, or environmental conditions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce

Definitions

  • the present invention provides a “Jam Factor” rating that represents the status along a specified driving route.
  • the driving route is specified such that the route includes at least one road.
  • a free flow travel time is calculated for the specified route.
  • the total delay is calculated for the specified route.
  • the free flow travel time and the total delay are summed to obtain the total estimated travel time along the specified route.
  • a delay multiple is then calculated by dividing the total travel time by the free flow travel time.
  • the Jam Factor rating is then calculated based on the delay multiple.
  • FIG. 1 shows generic examples of Jam Factors for various traffic situations.
  • FIG. 2 shows specific examples of Jam Factors for the commute segment I-76 from the PA Turnpike to the Walt Whitman Bridge.
  • FIG. 3 a shows the user interface display screen for selecting a drive name and metro (metropolitan) area.
  • FIG. 3 b shows the user interface display screen for selecting a starting roadway.
  • FIG. 3 c shows the user interface display screen for selecting start and end points on starting road.
  • FIG. 3 d shows the user interface display screen for selecting a continuation to a connecting roadway.
  • FIG. 3 e shows the user interface display screen for selecting to end a commute.
  • FIG. 3 f shows the user interface display screen for viewing drives and overall Jam Factor for those drives.
  • FIG. 3 g shows the user interface display screen for viewing the Jam Factor (item 10) for the individual roadway sections along a specific previously created drive. Additionally, the display also shows incidents (item 20) on the individual roadway sections.
  • FIG. 4 a shows the Magnet Product Page which a user will see when they first access the magnet website (or are not logged in).
  • FIG. 4 b shows a screenshot of the pages of the Traffic Magnet registration page where user information is entered.
  • FIG. 4 c shows a screenshot of the Traffic Magnet registration page that displays the User Agreement and Privacy Policy.
  • FIG. 4 d shows an example of a magnet on the maintenance page.
  • FIG. 4 e shows a screenshot of the magnet creation page where user information is entered.
  • FIG. 4 f shows a screenshot of the magnet creation page where the format of the magnet is selected.
  • FIG. 5 shows examples of the layouts of a horizontal magnet and a vertical magnet.
  • FIG. 6 shows some of the different styles of magnets available to the user.
  • FIG. 7 shows the database schema for the Traffic Magnet data.
  • FIG. 8 shows a Data Flow Diagram for the user interface for the creation of a Traffic Magnet.
  • the present invention is described in the context of two services, namely, TrafficMagnetsTM and Jam FactorTM reports, both of which are commercially available from Traffic.com, Wayne, Pa.
  • the scope of the present invention includes other embodiments that may differ from the specific implementations provided by the TrafficMagnets and Jam Factor reports.
  • the present invention is also preferably designed to work in conjunction with systems and methods described in copending U.S. patent application Ser. No. 10/611,494 filed on Jun. 30, 2003, entitled “Method of Creating a Virtual Traffic Network,” which is hereby incorporated by reference.
  • the scope of the invention includes embodiments that do not necessarily incorporate the methods and apparatus described in this patent application.
  • the jam factor of a route is a value between 0 and 10 which indicates the ease of travel along the route. All clear would be a number towards 0, and completely jammed/stopped would be a number towards 10. Jam Factor calculations will be done primarily through delays (from free flow travel).
  • Determining delay for a digital route is done through sensor values. For a non-digital route, the delay is calculated through the incidents along the route. For routes which contain both digital and non-digital sections, separate calculations are done for each section and the final delays are added together.
  • the delay is calculated from the real-time sensor values. If there are any problems determining the delay from the sensors (sensors are no longer working, data is determined to be invalid), then the non-digital calculations are used for this route. Also, traffic items are still checked to determine if there is a road closure. Otherwise, traffic items are ignored for digital routes.
  • DigitalDelay RouteLength SensorSpeed - RouteLength SpeedLimit In the preferred embodiment of the present invention, the delay is never expressed as a negative number. Thus, if traffic is moving faster than the speed limit, the delay is reported as being zero. 2. Delay for Non-Digital Routes:
  • Delay for non-digital routes is calculated through the traffic items that occur along the route. There are two separate delays that are calculated, one for the congestion items and one for high criticality items which are not attributed (or linked) to a congestion item.
  • Each congestion item will have a type associated with it which describes the level of congestion seen along the road. These congestion types will map to an estimated average speed, allowing a travel time to be calculated for the length of the congestion. Individual congestion delays will then be determined by calculating the difference between the free flow travel time and the congestion travel time. The total congestion delay will be the sum of all the individual congestion item delays.
  • CongestionTT CongItemLength
  • CongItemSpeed FreeFlowTT CongItemLength RouteSpeedLimit
  • This Delay Multiple can be directly associated to the Jam Factor by an exponential equation where the Jam Factor equals 0 when the delay multiple equals 1 (no delay) and the Jam Factor approaches 10 as the delay multiple grows very large. A set of logical plot points along the curve was determined to create a graph of Jam Factor vs. Delay Multiple. Linear interpolation can then be used to determine the jam factor when the delay multiple lies between the plot points.
  • FIG. 1 shows generic examples of Jam Factors for various traffic situations.
  • FIG. 2 shows specific examples of Jam Factors for the commute segment I-76 from the PA Turnpike to the Walt Whitman Bridge.
  • FIGS. 3 a through 3 g describe the process of creating a drive and viewing a Jam Factor for that drive. These figures are self-explanatory and thus will be described only briefly.
  • FIG. 3 a shows the user interface display screen for selecting a drive name and metropolitan area.
  • FIG. 3 b shows the user interface display screen for selecting a starting roadway.
  • FIG. 3 c shows the user interface display screen for selecting start and end points on starting road.
  • FIG. 3 d shows the user interface display screen for selecting a continuation to a connecting roadway.
  • FIG. 3 e shows the user interface display screen for selecting to end a commute.
  • FIG. 3 f shows the user interface display screen for viewing drives and overall Jam Factor for those drives.
  • the Traffic magnet project can be separated into two distinct components: (1) Traffic Magnet registration/maintenance, and (2) Traffic Magnet generation.
  • the user interface for creating traffic magnets is preferably web based, and located at http://magnet.traffic.com.
  • FIG. 4 a shows the Magnet Product Page which a user will see when they first access the magnet website (or are not logged in). This page will show examples of the various magnets that they can create for their website. From this page, a user can register for the service, or login if they have already registered.
  • FIGS. 4 b and 4 c show the registration page.
  • the following data will be requested from the user: TABLE 4 User Registration Information: First Name Optional. Last Name Optional. User Name Required. 6-12 characters Password Required. 6-12 characters E-mail Address Required. Company Name Optional. Phone Number Optional. Street Address 1 Optional. Street Address 2 Optional. City Optional. State Optional. Zip Code Optional.
  • the user must enter in the required fields, and also agree to the terms and conditions for using the magnet service, in order to create an account.
  • the data entered is saved in the traffic_user table in the database.
  • the user creation date is also saved to verify when the user signed up and agreed to the terms and conditions.
  • FIG. 7 shows the database schema.
  • FIG. 3 g shows the user interface display screen for viewing the Jam Factor (item 10) for the individual roadway sections along a specific previously created drive. Additionally, the display also shows incidents (item 20) on the individual roadway sections.
  • a Traffic Magnet is a snippet of programming code that allows an end user to include live traffic information on their web site and provides a link from their site to a remote site containing the traffic information, such as Traffic.com.
  • a remote site is defined as an entity other than the internet or intranet content provider.
  • Placing a Traffic Magnet on a web site allows the end user to provide live traffic information about the roads surrounding the end user's physical location to users of their web site who will travel to or from that physical location. Additionally, having such links embedded in many web sites provide benefits to the remote site (here, Traffic.com), such as driving internet traffic to the remote website, increasing brand awareness of the remote site, and improving search engine ranking of the remote site (when done using embedded HTML).
  • One preferred embodiment of a web-based Traffic Magnet product allows Traffic.com users to configure the magnet by selecting up to four roadways to track (in both directions), and one of several backgrounds. Configuration occurs through a web interface. Registration is preferably required for access to this interface. The output of the product is a snippet of HTML/Javascript that the user paste into their web page. Traffic information in the magnet will be provided on a Route basis. A single magnet will show several Routes but they must all belong to the same metropolitan area. Traffic.com may have the ability limit the number of magnets a user can create, but most likely there would not be a limit unless users abused the service. The terms and conditions may include a clause about users not abusing the service.
  • magnets may have some static links which need to remain functional. Also, it is possible for the magnets to contain hardcoded route ID's. If they do, these keyroutes must not be deleted and the ID's must not be changed.
  • Tracking and Reporting site traffic A user's magnets will be stored in the database. By attaching this magnet ID or user ID to all the inbound links, Traffic.com can track the traffic generated by specific users.
  • the style of the magnet will determine the magnet size.
  • Each magnet style has a standard size (e.g., 410 ⁇ 285 horizontal, 200 ⁇ 605 vertical).
  • magnet styles will be contained in the database (Refer to FIG. 7 for the database schema).
  • the styles will define the layout, background, orientation and color scheme of the magnet. A user will select from one of these styles when creating their magnet.
  • the following fields will be needed to define a magnet style. TABLE 5 Fields Defining Magnet Style Magnet Magnet Style Name Name of Magnet Position H (Horizontal) or V (Vertical) Image Example Image File Name Width Width of the magnet Height Height of the magnet Velocity Template Template defining the html style and format for this magnet
  • magnets during creation in order to select the style they want for their website.
  • terms of service must outline proper use of magnet. e.g. magnet can only exist at domain on one (1) page, etc.
  • Traffic magnets are displayed through a code snippet that a user places on their website.
  • the code snippet will contain links to javascript files located on the traffic.com servers, as well as some static html.
  • the javascript files will be auto generated on a regular basis so that a user is accessing a static file.
  • the traffic magnets will contain links back to specific areas on the www.traffic.com website. All links and images in the magnet will have a referral id to track statistics on magnets. HTML provided will be standards compliant and valid, with all styling accomplished through the use of inline CSS.
  • FIG. 5 shows examples of the layouts of a horizontal magnet and a vertical magnet.
  • the process for generating magnets needs to be a compromise between flexibility, security and scalability.
  • One preferred solution is to use Javascript as the main piece of the code snippet that the user pastes on their webpage. This is not as scalable as using straight HTML code, but gives much more flexibility to change the content of the magnet without affecting the user's website. It also makes it more difficult for the user to try and modify the look of the magnet (which should be a violation of the Terms and Conditions).
  • the downside to this solution is that it will not improve the search engine ranking. To try and overcome the search engine ranking problem, some static html must be included in the magnet code snippet which refers back to the traffic.com website.
  • the javascript will be contained in files on traffic.com servers, and the user's code snippet will simply point to the proper files for the respective magnet.
  • the javascript will be generated in two parts. One part will generate the user's magnet code in a file named magnet.js. The other part will generate the code for each route section of the magnet in files named keyroutedetails.js. A single magnet code snippet will then point to one magnet.js file (which will include references to the applicable keyroutedetails.js files).
  • Traffic.com can enforce that each link on the magnet will contain information identifying the magnet user. This will allow Traffic.com to easily track the traffic coming from each user/magnet through the Apache web logs.
  • Route information will be pre-generated every two minutes for each known route in the metro area.
  • the process will create ajavascript file (keyroutedetails.js) and an incident icon (incident.gif) for every route. This information will be shared by all magnets which contain the same route.
  • the keyroutedetails.js file will contain methods for retrieving the timestamp and jam factor for a route.
  • the incident icon will be an image file determined through the incidents along the route.
  • the two generated files will be placed on the magnet.traffic.com server in a location similar to keyroutes/metro ⁇ metroid>/keyroute ⁇ routeid>_ ⁇ route-direction>.
  • the text in between “ ⁇ >” is text that is replaced by real data during processing.
  • the magnet Javascript file will be pre-generated on an as-needed basis. All active magnets will be created when the magnet generation process starts. After the initial creation pass, the process will check for all magnets labeled as “dirty” to recreate. A magnet may be labeled as dirty when:
  • Magnet information consists of the magnet.js file and symbolic links pointing to the route directory (created by the process noted above) for each route in the magnet. This information is placed in a location similar to magnets/metro ⁇ metroid>/ ⁇ userid>/ ⁇ magnetid>.js.
  • the symbolic links hide the actual location of the keyroute information so users cannot easily find and use content outside of their magnet definition. When a magnet is deleted, the symbolic links are broken and a “deleted” version of the magnet.js file is created. In this manner, the user no longer has access to any of the information.
  • FIG. 6 shows some of the different styles of magnets available to the user.
  • Magnet style templates are saved in the database and used to generate the magnet.js file. There are multiple styles that the user can choose from for displaying the selected route content. The user chooses a style for each magnet. The user also selects the routes which will appear on the magnet. When a magnet is generated, the style template is pulled from the database and the selected routes are used to create the route sections. The route name, direction, ID, shield type and roadway number are all needed by the template.
  • the real-time parts of the magnet are the timestamp, the jam factor for each route, and the incident icon for each route.
  • the content of the magnet javascript file changes very infrequently, but will still contain real-time data by calling methods on the above-generated keyroutedetails.js files.
  • the jam factor method called will be determined by the magnet orientation (horizontal/vertical) and route ID's. For example, the method getHorizJamFactor456( ) will be used for route 456 in a horizontal magnet.
  • the time is retrieved by calling getTime( ) which exists in each keyroutedetails.js file and should have the same time for all routes in a metro.
  • the incident icon (incident.gif) for each route, which changes with the keyroutedetails.js file, is included in the magnet through the symbolic link paths.
  • only traffic conditions are requested from the remote site.
  • the user retrieves all of the code in the snippet needed to assemble the magnet, and the dynamic pieces of the magnet (traffic data), via XML.
  • the code snippet is a link to a javascript file, it is a snippet of html and javascript which creates the entire magnet, minus the real time traffic data.
  • the traffic data (and only the traffic data) can then be downloaded on a regular basis from the Traffic.com web site to fill in on the magnet.
  • the XML can be generated as a separate file for each metropolitan area containing the real-time data for the metropolitan area keyroutes.
  • FIG. 8 shows a Data Flow Diagram for the user interface. The steps in the diagram are explained as follows:
  • the application checks if there are any browser cookies available which specify that the user has already logged in.
  • magnet If magnet is successfully created, the user is redirected back to the magnet maintenance page to see their new magnet and the code snippet necessary to place on their website (the actual magnet may take a few minutes before it can be seen on the page, but the code snippet is available immediately).
  • the user is directed back to the magnet creation page (with all their selected values pre-filled) and a message specifying which form field needs to be addressed to fix the problem.
  • the user is redirected to the login screen to use their newly created username and password for entry into the magnet website.
  • the user can login from the home page by entering their username and password into the proper fields.
  • the login is successful, the user will be redirected to the magnet maintenance page. If the login is not successful, they will be redirected back to the login page and notified that their username/password combination was incorrect.
  • the necessary data for reporting internet traffic from traffic magnets is collected and saved. Accordingly, statistics can be generated at any time.
  • the other set of data is the web traffic information related to the magnets and is collected through Apache server web logs. All URLs in the magnets contain a reference to the current magnet, which not only allows Traffic.com to determine the number of times the magnet is loaded, but also which magnets are driving traffic back to the main website. All Apache web logs are saved off to a separate server on a daily basis. These logs can be parsed by a Perl script or Java process to retrieve necessary information. Tables 11-13 outline the requested reporting areas.
  • the result data can either be stored in the database or emailed to a specific list of addresses.
  • the present invention may be implemented with any combination of hardware and software. If implemented as a computer-implemented apparatus, the present invention is implemented using means for performing all of the steps and functions described above.
  • the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer useable media.
  • the media has embodied therein, for instance, computer readable program code means for providing and facilitating the mechanisms of the present invention.
  • the article of manufacture can be included as part of a computer system or sold separately.

Abstract

A Jam Factor rating is provided that represents the status along a specified route. A free flow travel time is calculated for the specified route. An estimated travel time is calculated for the specified route by considering traffic conditions along the specified route. A delay assessment is determined by comparing the estimated total travel time to the free flow travel time. The Jam Factor rating is based on the delay assessment.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application is a continuation of application Ser. No. 11/703,442 filed Feb. 7, 2007, which was a division of U.S. application Ser. No. 11/376,731, now U.S. Pat. No. 7,203,595, filed Mar. 15, 2006, the entire disclosure of which is incorporated by reference herein. U.S. application Ser. No. 11/376,731, now U.S. Pat. No. 7,203,595, filed Mar. 15, 2006, is related to previously filed U.S. application Ser. No. 11/376,715 filed Mar. 15, 2006, entitled “Method of displaying traffic information on a web page.”
  • BACKGROUND OF THE INVENTION
  • Currently, when information about traffic on a road or series of roads is communicated in commercial broadcasts, written traffic reports or even in casual conversation, terms such as ‘jammed’, ‘bottled up’, ‘moderate’ and ‘heavy’ are often used. These terms provide little or no specific information to the listener or viewer. Terms such as these are imprecise in that they simply express that traffic is not traveling at the maximum potential speed for the road. Additionally, terms such as these are very subjective. What one person might describe as ‘moderate’, another person might describe as ‘jammed’ based on their frame of reference. Yet, most people would agree that ‘moderate’ and ‘jammed’ are not equivalent descriptions of traffic conditions. What is needed is an objective, precise, quantitative way to express information about the level of traffic so that a listener or viewer of that rating will have an understanding of the meaning of that information and that the information will be useful to them.
  • BRIEF SUMMARY OF THE INVENTION
  • The present invention provides a “Jam Factor” rating that represents the status along a specified driving route. The driving route is specified such that the route includes at least one road. A free flow travel time is calculated for the specified route. Then, the total delay is calculated for the specified route. The free flow travel time and the total delay are summed to obtain the total estimated travel time along the specified route. A delay multiple is then calculated by dividing the total travel time by the free flow travel time. The Jam Factor rating is then calculated based on the delay multiple.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The foregoing summary, as well as the following detailed description of preferred embodiments of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings embodiments which are presently preferred. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
  • In the drawings:
  • FIG. 1 shows generic examples of Jam Factors for various traffic situations.
  • FIG. 2 shows specific examples of Jam Factors for the commute segment I-76 from the PA Turnpike to the Walt Whitman Bridge.
  • FIG. 3 a shows the user interface display screen for selecting a drive name and metro (metropolitan) area.
  • FIG. 3 b shows the user interface display screen for selecting a starting roadway.
  • FIG. 3 c shows the user interface display screen for selecting start and end points on starting road.
  • FIG. 3 d shows the user interface display screen for selecting a continuation to a connecting roadway.
  • FIG. 3 e shows the user interface display screen for selecting to end a commute.
  • FIG. 3 f shows the user interface display screen for viewing drives and overall Jam Factor for those drives.
  • FIG. 3 g shows the user interface display screen for viewing the Jam Factor (item 10) for the individual roadway sections along a specific previously created drive. Additionally, the display also shows incidents (item 20) on the individual roadway sections.
  • FIG. 4 a shows the Magnet Product Page which a user will see when they first access the magnet website (or are not logged in).
  • FIG. 4 b shows a screenshot of the pages of the Traffic Magnet registration page where user information is entered.
  • FIG. 4 c shows a screenshot of the Traffic Magnet registration page that displays the User Agreement and Privacy Policy.
  • FIG. 4 d shows an example of a magnet on the maintenance page.
  • FIG. 4 e shows a screenshot of the magnet creation page where user information is entered.
  • FIG. 4 f shows a screenshot of the magnet creation page where the format of the magnet is selected.
  • FIG. 5 shows examples of the layouts of a horizontal magnet and a vertical magnet.
  • FIG. 6 shows some of the different styles of magnets available to the user.
  • FIG. 7 shows the database schema for the Traffic Magnet data.
  • FIG. 8 shows a Data Flow Diagram for the user interface for the creation of a Traffic Magnet.
  • DETAILED DESCRIPTION OF THE INVENTION
  • Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention. In the drawings, the same reference letters are employed for designating the same elements throughout the several figures.
  • The present invention is described in the context of two services, namely, TrafficMagnets™ and Jam Factor™ reports, both of which are commercially available from Traffic.com, Wayne, Pa. However, the scope of the present invention includes other embodiments that may differ from the specific implementations provided by the TrafficMagnets and Jam Factor reports. The present invention is also preferably designed to work in conjunction with systems and methods described in copending U.S. patent application Ser. No. 10/611,494 filed on Jun. 30, 2003, entitled “Method of Creating a Virtual Traffic Network,” which is hereby incorporated by reference. However, the scope of the invention includes embodiments that do not necessarily incorporate the methods and apparatus described in this patent application.
  • I. Overview of Jam Factor Rating
  • The jam factor of a route is a value between 0 and 10 which indicates the ease of travel along the route. All clear would be a number towards 0, and completely jammed/stopped would be a number towards 10. Jam Factor calculations will be done primarily through delays (from free flow travel).
  • Determining delay for a digital route is done through sensor values. For a non-digital route, the delay is calculated through the incidents along the route. For routes which contain both digital and non-digital sections, separate calculations are done for each section and the final delays are added together.
  • Any road closure along the route will automatically create a Jam Factor of 10.
  • II. Calculations of Jam Factor Rating
  • 1. Delay for Digital Routes:
  • The delay is calculated from the real-time sensor values. If there are any problems determining the delay from the sensors (sensors are no longer working, data is determined to be invalid), then the non-digital calculations are used for this route. Also, traffic items are still checked to determine if there is a road closure. Otherwise, traffic items are ignored for digital routes. DigitalDelay = RouteLength SensorSpeed - RouteLength SpeedLimit
    In the preferred embodiment of the present invention, the delay is never expressed as a negative number. Thus, if traffic is moving faster than the speed limit, the delay is reported as being zero.
    2. Delay for Non-Digital Routes:
  • Delay for non-digital routes is calculated through the traffic items that occur along the route. There are two separate delays that are calculated, one for the congestion items and one for high criticality items which are not attributed (or linked) to a congestion item.
  • a. Congestion Delay:
  • Each congestion item will have a type associated with it which describes the level of congestion seen along the road. These congestion types will map to an estimated average speed, allowing a travel time to be calculated for the length of the congestion. Individual congestion delays will then be determined by calculating the difference between the free flow travel time and the congestion travel time. The total congestion delay will be the sum of all the individual congestion item delays. CongestionTT = CongItemLength CongItemSpeed FreeFlowTT = CongItemLength RouteSpeedLimit CongestionDelay = i = 1 £ congitems ( CongestionTT i - FreeFlowTT i )
    TABLE 1
    Congestion Speeds (based upon 60 mph roads):
    Congestion Type Speed (mph)
    Stopped 2
    Jammed 10
    Generally Jammed 20
    Slow 30
    Generally Slow 40
    Sluggish 48

    Note:

    For roads with speed limits other than 60 mph, the congestion speeds will be adjusted according to the same percentages.

    b. Incident Delay:
  • Incidents must be taken into account when there are no corresponding congestion items linked to them. A value will be looked up in a table that matches incident attributes with assumed delays. In one preferred embodiment, only the criticality of the incident is taken into account. All incidents that have a child congestion item will be ignored since they should already be accounted for by the congestion calculation above. IncidentDelay = i = 1 £ items ( Delay i )
  • The following table may be used to map the criticalities of incidents to an estimated delay.
    TABLE 2
    Criticality Delays:
    Criticality Delay (min)
    0 20
    1 10
    2 5
    3 2

    3. Jam Factor:
  • The Jam Factor is determined by first comparing the estimated travel time to the free flow travel time. This comparison is referred to as the Delay Multiple. DelayMultiple = FreeFlowTT + TotalDelay FreeFlowTT where : FreeFlowTT = KR_Length SpeedLimit
  • This Delay Multiple can be directly associated to the Jam Factor by an exponential equation where the Jam Factor equals 0 when the delay multiple equals 1 (no delay) and the Jam Factor approaches 10 as the delay multiple grows very large. A set of logical plot points along the curve was determined to create a graph of Jam Factor vs. Delay Multiple. Linear interpolation can then be used to determine the jam factor when the delay multiple lies between the plot points.
  • Below is a table of delay multiples with expected Jam Factors.
    TABLE 3
    JamFactor Points:
    Speed
    Delay Based on 60 mph
    Point # Multiple Jam Factor limit
    1 1 0 60
    2 1.25 3 48
    3 1.5 5 40
    4 1.75 6 34.2
    5 2 7 30
    6 3 8 20
    7 8 9 7.5
    8 32 10 2
  • To calculate the Jam Factor for a specific delay multiple, the following equation is used (which utilizes the two points that the delay multiple falls between):
    • prev=point preceding the actual delay multiple
    • next=point following the actual delay multiple JamFactor = JamFactor next - JamFactor prev DelayMultiple next - DelayMultiple prev * ( DelayMultiple actual - DelayMultiple next ) + JamFactor next
  • FIG. 1 shows generic examples of Jam Factors for various traffic situations.
  • FIG. 2 shows specific examples of Jam Factors for the commute segment I-76 from the PA Turnpike to the Walt Whitman Bridge.
  • III. Creating and Viewing a Jam Factor Rating
  • FIGS. 3 a through 3 g describe the process of creating a drive and viewing a Jam Factor for that drive. These figures are self-explanatory and thus will be described only briefly.
  • FIG. 3 a shows the user interface display screen for selecting a drive name and metropolitan area.
  • FIG. 3 b shows the user interface display screen for selecting a starting roadway.
  • FIG. 3 c shows the user interface display screen for selecting start and end points on starting road.
  • FIG. 3 d shows the user interface display screen for selecting a continuation to a connecting roadway.
  • FIG. 3 e shows the user interface display screen for selecting to end a commute.
  • FIG. 3 f shows the user interface display screen for viewing drives and overall Jam Factor for those drives.
  • V. Specifications for a Traffic Magnet
  • The Traffic magnet project can be separated into two distinct components: (1) Traffic Magnet registration/maintenance, and (2) Traffic Magnet generation.
  • 1. Traffic Magnet Registration/Maintenance
  • The user interface for creating traffic magnets is preferably web based, and located at http://magnet.traffic.com.
  • FIG. 4 a shows the Magnet Product Page which a user will see when they first access the magnet website (or are not logged in). This page will show examples of the various magnets that they can create for their website. From this page, a user can register for the service, or login if they have already registered.
  • a. Registration
  • FIGS. 4 b and 4 c show the registration page. The following data will be requested from the user:
    TABLE 4
    User Registration Information:
    First Name Optional.
    Last Name Optional.
    User Name Required. 6-12 characters
    Password Required. 6-12 characters
    E-mail Address Required.
    Company Name Optional.
    Phone Number Optional.
    Street Address 1 Optional.
    Street Address 2 Optional.
    City Optional.
    State Optional.
    Zip Code Optional.
  • The user must enter in the required fields, and also agree to the terms and conditions for using the magnet service, in order to create an account. The data entered is saved in the traffic_user table in the database. The user creation date is also saved to verify when the user signed up and agreed to the terms and conditions. FIG. 7 shows the database schema.
  • After the user successfully creates an account, they can then log into the system with their newly created username and password.
  • FIG. 3 g shows the user interface display screen for viewing the Jam Factor (item 10) for the individual roadway sections along a specific previously created drive. Additionally, the display also shows incidents (item 20) on the individual roadway sections.
  • IV. Overview of a Traffic Magnet
  • A Traffic Magnet is a snippet of programming code that allows an end user to include live traffic information on their web site and provides a link from their site to a remote site containing the traffic information, such as Traffic.com. A remote site is defined as an entity other than the internet or intranet content provider.
  • Placing a Traffic Magnet on a web site allows the end user to provide live traffic information about the roads surrounding the end user's physical location to users of their web site who will travel to or from that physical location. Additionally, having such links embedded in many web sites provide benefits to the remote site (here, Traffic.com), such as driving internet traffic to the remote website, increasing brand awareness of the remote site, and improving search engine ranking of the remote site (when done using embedded HTML).
  • One preferred embodiment of a web-based Traffic Magnet product allows Traffic.com users to configure the magnet by selecting up to four roadways to track (in both directions), and one of several backgrounds. Configuration occurs through a web interface. Registration is preferably required for access to this interface. The output of the product is a snippet of HTML/Javascript that the user paste into their web page. Traffic information in the magnet will be provided on a Route basis. A single magnet will show several Routes but they must all belong to the same metropolitan area. Traffic.com may have the ability limit the number of magnets a user can create, but most likely there would not be a limit unless users abused the service. The terms and conditions may include a clause about users not abusing the service.
  • Backwards compatibility—magnets may have some static links which need to remain functional. Also, it is possible for the magnets to contain hardcoded route ID's. If they do, these keyroutes must not be deleted and the ID's must not be changed.
  • Tracking and Reporting site traffic—A user's magnets will be stored in the database. By attaching this magnet ID or user ID to all the inbound links, Traffic.com can track the traffic generated by specific users.
  • b. Magnet Maintenance
  • FIG. 4 d shows an example of a magnet on the maintenance page. After a user is logged in, they will be forwarded to the magnet maintenance page where they will see a list of their previously created magnets. The actual magnets will be displayed, along with a text block containing the magnet code snippet and a button to delete the magnet. Users will not be able to edit a magnet. If they want to change a magnet style, or the keyroutes associated with a magnet, they will need to delete it and create a new one.
  • c. Magnet Creation
  • After logging in, a user will also be able to create a new magnet. The style of the magnet will determine the magnet size. Each magnet style has a standard size (e.g., 410×285 horizontal, 200×605 vertical).
  • Information on magnet styles will be contained in the database (Refer to FIG. 7 for the database schema). The styles will define the layout, background, orientation and color scheme of the magnet. A user will select from one of these styles when creating their magnet. The following fields will be needed to define a magnet style.
    TABLE 5
    Fields Defining Magnet Style
    Magnet
    Magnet Style Name Name of Magnet
    Position H (Horizontal) or V (Vertical)
    Image Example Image File Name
    Width Width of the magnet
    Height Height of the magnet
    Velocity Template Template defining the html style and format for this
    magnet
  • Magnets will also contain links to the website, promotions, advertisements, etc. This information can be different between metropolitan areas and may be updated at random times. It will be separated into two sections on the magnets. Each section will have its own html. The users have no control over this information. The following data needs to be stored in the database to create these html blocks.
    TABLE 6
    Data for Creation of HTML Blocks
    Magnet HTML
    MetroId Metro Id of magnets that link will show up on
    Magnet HTML 1 HTML to be displayed in the first section
    Magnet HTML
    2 HTML to be displayed in the second section
  • The user will be shown examples of magnets during creation in order to select the style they want for their website. (Note: terms of service must outline proper use of magnet. e.g. magnet can only exist at domain on one (1) page, etc.)
  • FIGS. 4 e and 4 f show screenshots of the magnet creation page. The following information needs to be captured for each magnet that the user creates. This data not only defines the user's magnet, but also gives us more information to be used to better track how the magnet is being used. The user will be allowed to select up to four roads for a magnet (which will equate to eight routes, when direction is taken into account). Although a user may create magnets for different metropolitan areas, an individual magnet will only be applicable to a single metropolitan area.
    TABLE 7
    Information captured for each magnet a user creates
    User Magnet
    Company Name Optional.
    Industry Optional.
    Home Page Address Required.
    Traffic Page Address Required.
    Magnet Description Required.
    Magnet Style Name Required.
    Metro Id Required.
    Route Id 1 Required
    Route Id 2 Optional
    Route Id
    3 Optional
    Route Id
    4 Optional
  • After a user creates their magnet, they will be directed back to the magnet maintenance page where they can see their new magnet. They will also have access to the code snippet to include the magnet on their website.
  • d. Traffic Magnet Creation Use Cases
    TABLE 8
    Steps - User registers for a magnet account
    UC01 Use Case 1
    User registers for a magnet account
    Step User Action Result Figure Alternate
    1 User goes to User sees Magnet Product N/A
    magnet.traffic.com Page
    2 User Clicks on “Sign Up Go to registration page FIG. 2b &
    Now” button 2c
    3 User Enters Values defined User is now registered standard
    in 0 and submits form error
  • TABLE 9
    Steps - User logs into magnet account
    UC02 Use Case 2
    User logs into magnet account
    Assumes user has registered and verified email address
    Step User Action Result Figure Alternate
    1 User clicks on “Login” link Go to login N/A
    page
    2 User enters name and Go to magnet Standard
    password and clicks submit maintenance error
    page
  • TABLE 10
    Steps - Registered User Creates a Traffic Magnet
    UC03 Use Case 3
    Registered User Creates a Traffic Magnet
    Assumes user has registered and logged in explicitly during this session.
    Step User Action Result Figure Alternate
    1 Chooses to create magnet Go to magnet set up page FIG. 2e & N/A
    2f
    2 Enter Company, Site N/A standard
    information error
    This information is required. Alternate processing is standard error handling for
    these elements.
    3 Enter Magnet Values N/A standard
    error
    User selects metro area, which populates keyroute list. User can select up to 4
    keyroutes (Javascript validation), and one background image.
    4 Confirm Legal Agreement N/A standard
    error
    User is required to check on “Agree” radio button.
    5 User selects ‘continue’ Go to Magnet Maintenence
    Magnet maintenance page gives user some indication about how to use html
    snippet and provides code in a scrolling text pane. User has to copy HTML in
    order to paste into their page.

    VI. Traffic Magnet Generation
  • Traffic magnets are displayed through a code snippet that a user places on their website. The code snippet will contain links to javascript files located on the traffic.com servers, as well as some static html. The javascript files will be auto generated on a regular basis so that a user is accessing a static file. The traffic magnets will contain links back to specific areas on the www.traffic.com website. All links and images in the magnet will have a referral id to track statistics on magnets. HTML provided will be standards compliant and valid, with all styling accomplished through the use of inline CSS.
  • a. Example Magnets
  • FIG. 5 shows examples of the layouts of a horizontal magnet and a vertical magnet.
  • b. Magnet Content
  • A Magnet will be applicable to a single metropolitan area and will contain information on one to four routes. Each route section of the magnet may contain any or all of the following information:
  • Roadway Name and Direction
    • Roadway Shield (if applicable to the road)—Four different shield types (U.S. state, interstate, county) with the road number overlaid on top.
    • Incident Icon—Triangle with the number of incidents along route inside. The triangle border will be colored red if there are any high criticality incidents, and yellow if there are any medium criticality incidents.
    • Jam Factor—Visual representation of route conditions, equating to a number between 0 and 10.
    • The magnet will also contain the following information: Metro Name, Timestamp of route data, and two sections for metropolitan specific advertisements and links.
    c. One Preferred Embodiment for Generating Magnets
  • The process for generating magnets needs to be a compromise between flexibility, security and scalability. One preferred solution is to use Javascript as the main piece of the code snippet that the user pastes on their webpage. This is not as scalable as using straight HTML code, but gives much more flexibility to change the content of the magnet without affecting the user's website. It also makes it more difficult for the user to try and modify the look of the magnet (which should be a violation of the Terms and Conditions). The downside to this solution is that it will not improve the search engine ranking. To try and overcome the search engine ranking problem, some static html must be included in the magnet code snippet which refers back to the traffic.com website.
  • The javascript will be contained in files on traffic.com servers, and the user's code snippet will simply point to the proper files for the respective magnet. The javascript will be generated in two parts. One part will generate the user's magnet code in a file named magnet.js. The other part will generate the code for each route section of the magnet in files named keyroutedetails.js. A single magnet code snippet will then point to one magnet.js file (which will include references to the applicable keyroutedetails.js files).
  • Since the user cannot directly manipulate the Javascript code, Traffic.com can enforce that each link on the magnet will contain information identifying the magnet user. This will allow Traffic.com to easily track the traffic coming from each user/magnet through the Apache web logs.
  • i. Route Information Generation
  • Route information will be pre-generated every two minutes for each known route in the metro area. The process will create ajavascript file (keyroutedetails.js) and an incident icon (incident.gif) for every route. This information will be shared by all magnets which contain the same route. The keyroutedetails.js file will contain methods for retrieving the timestamp and jam factor for a route. The incident icon will be an image file determined through the incidents along the route. The two generated files will be placed on the magnet.traffic.com server in a location similar to keyroutes/metro<metroid>/keyroute<routeid>_<route-direction>. The text in between “<>” is text that is replaced by real data during processing.
  • The incident icon is chosen from an incident image repository based upon the current incidents along the route. The image repository will contain all of the possible variations of incident icons (icons with yellow, red and clear borders as well as numbers from 0-9 inside). The proper image is selected by counting the number of incidents along the route (which determines the number) and finding the highest criticality incident (which determines the border, red for high criticality and yellow for medium criticality). The image file is renamed to incident.gif when moved to the route directory defined above.
  • The javascript file will contain a method for getting the timestamp of the data (getTime) and two methods to create the jam factor image (getVertJamFactor<routeid> for vertical magnets and getHorizJamFactor<routeid> for horizontal magnets). The jam factor image is created by using a static image for the multi-colored background bar and having 11 different rectangular slider bar locations for each integer from 0-10. The left most location will be 0, and the right most 10. The jam factor value will be truncated to one decimal place and shown on the rectangular slider. The slider location is determined by the whole number value of the jam factor. The slider color also changes with different locations.
  • ii. Magnet Information Generation
  • The magnet Javascript file will be pre-generated on an as-needed basis. All active magnets will be created when the magnet generation process starts. After the initial creation pass, the process will check for all magnets labeled as “dirty” to recreate. A magnet may be labeled as dirty when:
    • Magnet is created
    • Magnet is deleted
    • Route changes are made to the system, affecting specific route ID's
    • Design for a style changes
    • Magnet html for a metro changes.
  • Magnet information consists of the magnet.js file and symbolic links pointing to the route directory (created by the process noted above) for each route in the magnet. This information is placed in a location similar to magnets/metro<metroid>/<userid>/<magnetid>.js. The symbolic links hide the actual location of the keyroute information so users cannot easily find and use content outside of their magnet definition. When a magnet is deleted, the symbolic links are broken and a “deleted” version of the magnet.js file is created. In this manner, the user no longer has access to any of the information.
  • FIG. 6 shows some of the different styles of magnets available to the user. Magnet style templates are saved in the database and used to generate the magnet.js file. There are multiple styles that the user can choose from for displaying the selected route content. The user chooses a style for each magnet. The user also selects the routes which will appear on the magnet. When a magnet is generated, the style template is pulled from the database and the selected routes are used to create the route sections. The route name, direction, ID, shield type and roadway number are all needed by the template.
  • The real-time parts of the magnet are the timestamp, the jam factor for each route, and the incident icon for each route. The content of the magnet javascript file changes very infrequently, but will still contain real-time data by calling methods on the above-generated keyroutedetails.js files. The jam factor method called will be determined by the magnet orientation (horizontal/vertical) and route ID's. For example, the method getHorizJamFactor456( ) will be used for route 456 in a horizontal magnet. The time is retrieved by calling getTime( ) which exists in each keyroutedetails.js file and should have the same time for all routes in a metro. The incident icon (incident.gif) for each route, which changes with the keyroutedetails.js file, is included in the magnet through the symbolic link paths.
  • d. Alternative Embodiment for Generating Magnets
  • In another embodiment of the present invention, only traffic conditions are requested from the remote site. In this embodiment, the user retrieves all of the code in the snippet needed to assemble the magnet, and the dynamic pieces of the magnet (traffic data), via XML. Instead of the code snippet being a link to a javascript file, it is a snippet of html and javascript which creates the entire magnet, minus the real time traffic data. The traffic data (and only the traffic data) can then be downloaded on a regular basis from the Traffic.com web site to fill in on the magnet. The XML can be generated as a separate file for each metropolitan area containing the real-time data for the metropolitan area keyroutes.
  • VII. Data Flow Diagram for the User Interface
  • FIG. 8 shows a Data Flow Diagram for the user interface. The steps in the diagram are explained as follows:
  • 10. User specifically types in or is directed to the magnet.traffic.com domain
  • 20. The application checks if there are any browser cookies available which specify that the user has already logged in.
  • 30. If the login cookie exists, the user information is pulled from the cookie and the user is directed to the magnet maintenance page (See section V.1.b).
  • 40. User selects to create a new magnet and is directed to the magnet creation page to select the details of the new magnet (See section V.1.c).
  • 50. If magnet is successfully created, the user is redirected back to the magnet maintenance page to see their new magnet and the code snippet necessary to place on their website (the actual magnet may take a few minutes before it can be seen on the page, but the code snippet is available immediately).
  • If the magnet could not be created, the user is directed back to the magnet creation page (with all their selected values pre-filled) and a message specifying which form field needs to be addressed to fix the problem.
  • 60. If the user is not logged in when going to magnet.traffic.com, they will be directed to the magnet home page (See section V.1).
  • 70. If a user selects to register from the magnet home page, they are directed to the registration sign up form (See section V.1.a).
  • 80. If there was an error during registration, the user is redirected back to the registration page (with all their selected values pre-filled) and a message specifying which form field needs to be addressed to fix the problem.
  • If registration was successful, the user is redirected to the login screen to use their newly created username and password for entry into the magnet website.
  • 90. If a user has forgotten their password, they can enter their username on this form and receive an email containing their password.
  • 100. The user can login from the home page by entering their username and password into the proper fields.
  • 110. If the login is successful, the user will be redirected to the magnet maintenance page. If the login is not successful, they will be redirected back to the login page and notified that their username/password combination was incorrect.
  • VIII. Reporting Internet Traffic from Traffic Magnets
  • The necessary data for reporting internet traffic from traffic magnets is collected and saved. Accordingly, statistics can be generated at any time. There are two different sets of data being collected. One set is the information collected when the user is maintaining their magnets and is saved in the database. The other set of data is the web traffic information related to the magnets and is collected through Apache server web logs. All URLs in the magnets contain a reference to the current magnet, which not only allows Traffic.com to determine the number of times the magnet is loaded, but also which magnets are driving traffic back to the main website. All Apache web logs are saved off to a separate server on a daily basis. These logs can be parsed by a Perl script or Java process to retrieve necessary information. Tables 11-13 outline the requested reporting areas.
    TABLE 11
    Aggregate Data
    Aggregate Data: Grand Totals
    Total # of Accounts [db]
    # of Active Accounts (accessed in prior month)
    # of New Accounts (in prior month) [db]
    # of Deleted Accounts [db]
    Total # of Magnets [db]
    # of Active Magnets
    # of New Magnets [db]
    # of Deleted Magnets [db]
    # of Unique Users across all Accounts/Magnets
    # of Accesses/Pageviews across all Accounts/Magnets
    # of Clickthroughs to www.traffic.com
    Aggregate Data: Metro Totals - same as Grand Totals but broken down by
    Metro
  • TABLE 12
    Detailed Data for each Account/Magnet
    Detailed Data for each Account/Magnet:
    All Account and Magnet configuration info (Company, url, metro,
    Keyroute list, etc. [db]
    # of Unique Users per Magnet
    # of Accesses/Pageviews per Magnet
    # of Clickthroughs to www.traffic.com
  • TABLE 13
    Data for magnet.traffic.com web site
    Data for magnet.traffic.com web site
    # of UVs per Page (home page, signup, magnet setup, etc.)
    # of Pageviews per Page
    Ideally: Clickstream data to give visibility into where users go on the
    site (% who follow each link on each page vs. leave the site)
  • Some of this information will be determined through the database. The rest will need to parsed from the Apache web logs. After parsing the Apache web logs, the result data can either be stored in the database or emailed to a specific list of addresses.
  • The present invention may be implemented with any combination of hardware and software. If implemented as a computer-implemented apparatus, the present invention is implemented using means for performing all of the steps and functions described above.
  • The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer useable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the mechanisms of the present invention. The article of manufacture can be included as part of a computer system or sold separately.
  • It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention.

Claims (20)

1. A computer-implemented method of determining a rating that represents a status along a specified driving route comprising:
calculating a free flow travel time for the specified route;
calculating an estimated travel time for the specified route, said estimated travel time considers traffic conditions along the specified route;
determining a delay assessment by comparing the estimated total travel time to the free flow travel time; and
providing a rating based on the delay assessment.
2. The method of claim 1 wherein the free flow travel time for the specified route is calculated by dividing a length of the route by a speed limit for the route.
3. The method of claim 1 wherein the estimated travel time for the specified route is calculated by dividing a length of the route by an average speed of travel on the route.
4. The method of claim 3 wherein the average speed of travel is obtained from traffic sensors.
5. The method of claim 1 wherein the traffic conditions include traffic congestion.
6. The method of claim 1 wherein the traffic conditions include traffic incidents.
7. The method of claim 1 wherein the estimated travel time for the specified route is calculated by: (i) identifying areas of congestion along the route and areas without congestion along the route, (ii) determining a length of each area of congestion and a length of each area without congestion, (iii) determining an average speed for each area of congestion and an average speed for each area without congestion, (iv) calculating a travel time for each area of congestion by dividing the length of the area by the average speed for that area and a travel time for each area without congestion by dividing the length of the area by the average speed for that area, (v) summing the travel time for each area of congestion and each area without congestion along the route to determine the estimated travel time for the specified route.
8. The method of claim 1 wherein the estimated travel time for the specified route is calculated by: (i) identifying incidents along the route, (ii) determining the criticality of each incident along the route, (iii) determining an incident delay associated with each incident along the route which is based upon the criticality of the incident, (iv) summing the incident delays for each incident along the route, and (v) adding the sum to the free flow travel time to determine the estimated travel time for the specified route.
9. The method of claim 1 wherein if the estimated travel time divided by the free flow travel time is greater than a predetermined value, the rating indicates poor travel conditions.
10. The method of claim 1 wherein if the estimated travel time and the free flow travel time are approximately equal, the rating indicates good travel conditions.
11. A computer-implemented method of determining a rating that represents a status along a specified driving route comprising:
specifying a driving route that includes at least one road;
calculating a free flow travel time for the specified route;
calculating a delay along the specified route; and
providing a rating based on a comparison of the delay to said free flow travel time.
12. The method of claim 11 wherein the free flow travel time for the specified route is calculated by dividing a length of the route by a speed limit for the route.
13. The method of claim 11 wherein the delay is an amount of time that an estimated travel time for the specified route exceeds said free flow travel time, wherein said estimated travel time considers traffic conditions along the specified route.
14. The method of claim 11 wherein the delay includes a congestion delay, wherein said congestion delay is calculated by: (i) identifying a congested portion of the route having an average speed less than said speed limit, (ii) determining a length of the congested portion, and (iii) calculating a congestion travel time by dividing the length of the congested portion by the average speed for the congested portion.
15. The method of claim 11 wherein the delay includes an incident delay, wherein said incident delay is calculated by: (i) identifying an incident along the route, and (ii) determining an incident delay time amount associated with the incident.
16. The method of claim 11 wherein if the delay as compared to the free flow travel time is greater than a predetermined value, the rating indicates poor travel conditions.
17. A computer-implemented method of determining a traffic rating that represents a status along a road comprising:
calculating a free flow travel time for the road;
calculating an estimated travel time for the road considering traffic conditions on the road; and
determining said traffic rating based on a comparison of the estimated travel time to said free flow travel time.
18. The method of claim 17 wherein the free flow travel time for the specified route is calculated by dividing a length of the road by a speed limit for the road.
19. The method of claim 17 wherein the estimated travel time for the road is calculated by: (i) obtaining speed data for each portion of the road, (ii) determining a length of each portion of the road, (iii) calculating a travel time for each portion of the road by dividing the length of the portion by the speed for that portion, (v) summing the travel time for each portion.
20. A computer-implemented method of determining a traffic rating that represents the status along a road comprising:
calculating a delay along the road, the delay representing an amount of time needed to travel the road due to traffic conditions that exceeds an amount of time to travel the road during free flow conditions; and
providing said traffic rating based upon the delay.
US11/888,035 2006-03-15 2007-07-31 Rating that represents the status along a specified driving route Abandoned US20070299602A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/888,035 US20070299602A1 (en) 2006-03-15 2007-07-31 Rating that represents the status along a specified driving route

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/376,731 US7203595B1 (en) 2006-03-15 2006-03-15 Rating that represents the status along a specified driving route
US11/703,442 US7302341B1 (en) 2006-03-15 2007-02-07 Rating that represents the status along a specified driving route
US11/888,035 US20070299602A1 (en) 2006-03-15 2007-07-31 Rating that represents the status along a specified driving route

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/703,442 Continuation US7302341B1 (en) 2006-03-15 2007-02-07 Rating that represents the status along a specified driving route

Publications (1)

Publication Number Publication Date
US20070299602A1 true US20070299602A1 (en) 2007-12-27

Family

ID=37904301

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/376,731 Active US7203595B1 (en) 2006-03-15 2006-03-15 Rating that represents the status along a specified driving route
US11/703,442 Active US7302341B1 (en) 2006-03-15 2007-02-07 Rating that represents the status along a specified driving route
US11/888,035 Abandoned US20070299602A1 (en) 2006-03-15 2007-07-31 Rating that represents the status along a specified driving route
US11/926,597 Active 2029-09-19 US8234056B2 (en) 2006-03-15 2007-10-29 Rating that represents the status along a specified driving route

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US11/376,731 Active US7203595B1 (en) 2006-03-15 2006-03-15 Rating that represents the status along a specified driving route
US11/703,442 Active US7302341B1 (en) 2006-03-15 2007-02-07 Rating that represents the status along a specified driving route

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/926,597 Active 2029-09-19 US8234056B2 (en) 2006-03-15 2007-10-29 Rating that represents the status along a specified driving route

Country Status (1)

Country Link
US (4) US7203595B1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190113356A1 (en) * 2017-10-18 2019-04-18 Here Global B.V. Automatic discovery of optimal routes for flying cars and drones
US11035686B2 (en) 2018-08-31 2021-06-15 Here Global B.V. Use of geographic database comprising lane level information for traffic parameter prediction
US11669552B2 (en) 2018-08-31 2023-06-06 Here Global B.V. Use of geographic database comprising lane level information for traffic parameter prediction
EP3617651B1 (en) * 2018-08-31 2024-01-10 HERE Global B.V. Use of a geographic database comprising lane level information for traffic parameter prediction

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8452526B2 (en) * 2003-12-15 2013-05-28 Gary Ignatin Estimation of roadway travel information based on historical travel data
US7511634B2 (en) * 2004-12-22 2009-03-31 Htnb Corporation Retrieving and presenting dynamic traffic information
US20060241987A1 (en) * 2004-12-22 2006-10-26 Hntb Corporation Communication of project information
US7849031B2 (en) * 2004-12-22 2010-12-07 Hntb Holdings Ltd. Optimizing traffic predictions and enhancing notifications
JP2007011558A (en) * 2005-06-29 2007-01-18 Nissan Motor Co Ltd Apparatus and method for predicting traffic jam
US7486201B2 (en) * 2006-01-10 2009-02-03 Myweather, Llc Combined personalized traffic and weather report and alert system and method
US7203595B1 (en) * 2006-03-15 2007-04-10 Traffic.Com, Inc. Rating that represents the status along a specified driving route
US9514340B2 (en) * 2007-07-27 2016-12-06 Lucomm Technologies, Inc. Systems and methods for object localization and path identification based on RFID sensing
US20090228198A1 (en) * 2008-03-07 2009-09-10 Microsoft Corporation Selecting landmarks in shortest path computations
US8384564B2 (en) * 2009-03-06 2013-02-26 Navteq B.V. Method and system for adding gadgets to a traffic report
US9552726B2 (en) 2009-08-24 2017-01-24 Here Global B.V. Providing driving condition alerts using road attribute data
EP2556470A4 (en) 2010-04-06 2014-07-16 Right 90 Inc Trust rating metric for future event prediction of an outcome
US8706397B2 (en) * 2011-07-11 2014-04-22 Harman International Industries, Incorporated System and method for determining an optimal route using aggregated route information
CN103884347B (en) * 2012-12-21 2017-10-27 高德信息技术有限公司 A kind of navigation guide method and apparatus
WO2014197911A1 (en) * 2013-06-07 2014-12-11 Yandex Europe Ag Methods and systems for representing a degree of traffic congestion using a limited number of symbols
CN104751650B (en) * 2013-12-31 2017-06-20 中国移动通信集团公司 A kind of method and apparatus being controlled to road traffic signal
GB201512490D0 (en) * 2015-07-16 2015-08-19 Tomtom Traffic Bv Methods and systems for detecting a closure of a navigable element
GB201515487D0 (en) * 2015-09-01 2015-10-14 Tomtom Traffic Bv Methods and systems for detecting an open navigable element

Citations (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5272638A (en) * 1991-05-31 1993-12-21 Texas Instruments Incorporated Systems and methods for planning the scheduling travel routes
US5948040A (en) * 1994-06-24 1999-09-07 Delorme Publishing Co. Travel reservation information and planning system
US6285951B1 (en) * 1999-07-02 2001-09-04 Pri Automation, Inc. Dynamic traffic based routing algorithm
US6317686B1 (en) * 2000-07-21 2001-11-13 Bin Ran Method of providing travel time
US20020077742A1 (en) * 1999-03-08 2002-06-20 Josef Mintz Method and system for mapping traffic congestion
US20020082767A1 (en) * 1999-03-08 2002-06-27 Telquest, Ltd. Method and system for mapping traffic congestion
US6438490B2 (en) * 1998-04-28 2002-08-20 Xanavi Informatics Corporation Route searching device
US20020128773A1 (en) * 2001-03-09 2002-09-12 Chowanic Andrea Bowes Multiple navigation routes based on user preferences and real time parameters
US20030014180A1 (en) * 2001-07-10 2003-01-16 David Myr Method for regional system wide optimal signal timing for traffic control based on wireless phone networks
US6574548B2 (en) * 1999-04-19 2003-06-03 Bruce W. DeKock System for providing traffic information
US6594576B2 (en) * 2001-07-03 2003-07-15 At Road, Inc. Using location data to determine traffic information
US6650948B1 (en) * 2000-11-28 2003-11-18 Applied Generics Limited Traffic flow monitoring
US6701248B2 (en) * 2000-02-10 2004-03-02 Robert Bosch Gmbh Method of route planning in a navigation system
US20040068364A1 (en) * 2001-12-06 2004-04-08 Wei Zhao Automated location-intelligent traffic notification service systems and methods
US6748320B2 (en) * 1993-05-18 2004-06-08 Arrivalstar, Inc. Advance notification systems and methods utilizing a computer network
US6763299B2 (en) * 1993-05-18 2004-07-13 Arrivalstar, Inc. Notification systems and methods with notifications based upon prior stop locations
US20040143385A1 (en) * 2002-11-22 2004-07-22 Mobility Technologies Method of creating a virtual traffic network
US6845316B2 (en) * 2002-10-14 2005-01-18 Mytrafficnews.Com, Inc. Distribution of traffic and transit information
US20050027434A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation Information processing device, system thereof, method thereof, program thereof and recording medium storing such program
US20050027437A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation, Device, system, method and program for notifying traffic condition and recording medium storing the program
US20050027448A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation Device, system, method and program for notifying traffic condition and recording medium storing such program
US20060055565A1 (en) * 2004-09-10 2006-03-16 Yukihiro Kawamata System and method for processing and displaying traffic information in an automotive navigation system
US7082365B2 (en) * 2001-08-16 2006-07-25 Networks In Motion, Inc. Point of interest spatial rating search method and system
US7167795B2 (en) * 2003-07-30 2007-01-23 Pioneer Corporation Device, system, method and program for navigation and recording medium storing the program
US7203595B1 (en) * 2006-03-15 2007-04-10 Traffic.Com, Inc. Rating that represents the status along a specified driving route

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038559A (en) * 1998-03-16 2000-03-14 Navigation Technologies Corporation Segment aggregation in a geographic database and methods for use thereof in a navigation application
CA2266208C (en) * 1999-03-19 2008-07-08 Wenking Corp. Remote road traffic data exchange and intelligent vehicle highway system
US6285316B1 (en) * 2000-06-02 2001-09-04 Cellguide Ltd. Locating a mobile unit using signals from both mobile beacons and stationary beacons
US6615130B2 (en) * 2000-03-17 2003-09-02 Makor Issues And Rights Ltd. Real time vehicle guidance and traffic forecasting system
US6560532B2 (en) * 2001-05-25 2003-05-06 Regents Of The University Of California, The Method and system for electronically determining dynamic traffic information
US6704648B1 (en) * 2002-05-29 2004-03-09 Navigation Technologies Corp. Bearing data for route guidance
EP1577643A1 (en) * 2002-12-27 2005-09-21 Matsushita Electric Industrial Co., Ltd. Traffic information providing system, traffic information expression method and device
US7222018B2 (en) * 2004-04-06 2007-05-22 Honda Motor Co., Ltd. Bandwidth and memory conserving methods for a vehicle navigation system
US7502686B1 (en) * 2004-06-23 2009-03-10 Garmin Ltd. System and method utilizing non-GPS satellite content in real-time navigation
US20060161335A1 (en) * 2005-01-14 2006-07-20 Ross Beinhaker Routing system and method

Patent Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5272638A (en) * 1991-05-31 1993-12-21 Texas Instruments Incorporated Systems and methods for planning the scheduling travel routes
US6859722B2 (en) * 1993-05-18 2005-02-22 Arrivalstar, Inc. Notification systems and methods with notifications based upon prior package delivery
US6804606B2 (en) * 1993-05-18 2004-10-12 Arrivalstar, Inc. Notification systems and methods with user-definable notifications based upon vehicle proximities
US6763300B2 (en) * 1993-05-18 2004-07-13 Arrivalstar, Inc. Notification systems and methods with purpose message in notifications
US6763299B2 (en) * 1993-05-18 2004-07-13 Arrivalstar, Inc. Notification systems and methods with notifications based upon prior stop locations
US6748320B2 (en) * 1993-05-18 2004-06-08 Arrivalstar, Inc. Advance notification systems and methods utilizing a computer network
US5948040A (en) * 1994-06-24 1999-09-07 Delorme Publishing Co. Travel reservation information and planning system
US6438490B2 (en) * 1998-04-28 2002-08-20 Xanavi Informatics Corporation Route searching device
US6532414B2 (en) * 1999-03-08 2003-03-11 Josef Mintz Method and system for mapping traffic congestion
US20020082767A1 (en) * 1999-03-08 2002-06-27 Telquest, Ltd. Method and system for mapping traffic congestion
US20020077742A1 (en) * 1999-03-08 2002-06-20 Josef Mintz Method and system for mapping traffic congestion
US6542808B2 (en) * 1999-03-08 2003-04-01 Josef Mintz Method and system for mapping traffic congestion
US6574548B2 (en) * 1999-04-19 2003-06-03 Bruce W. DeKock System for providing traffic information
US6285951B1 (en) * 1999-07-02 2001-09-04 Pri Automation, Inc. Dynamic traffic based routing algorithm
US6701248B2 (en) * 2000-02-10 2004-03-02 Robert Bosch Gmbh Method of route planning in a navigation system
US6317686B1 (en) * 2000-07-21 2001-11-13 Bin Ran Method of providing travel time
US6650948B1 (en) * 2000-11-28 2003-11-18 Applied Generics Limited Traffic flow monitoring
US20020128773A1 (en) * 2001-03-09 2002-09-12 Chowanic Andrea Bowes Multiple navigation routes based on user preferences and real time parameters
US6594576B2 (en) * 2001-07-03 2003-07-15 At Road, Inc. Using location data to determine traffic information
US20030014180A1 (en) * 2001-07-10 2003-01-16 David Myr Method for regional system wide optimal signal timing for traffic control based on wireless phone networks
US6539300B2 (en) * 2001-07-10 2003-03-25 Makor Issues And Rights Ltd. Method for regional system wide optimal signal timing for traffic control based on wireless phone networks
US7082365B2 (en) * 2001-08-16 2006-07-25 Networks In Motion, Inc. Point of interest spatial rating search method and system
US20040068364A1 (en) * 2001-12-06 2004-04-08 Wei Zhao Automated location-intelligent traffic notification service systems and methods
US20070299601A1 (en) * 2001-12-06 2007-12-27 At&T Bls Intellectual Propety, Inc. Automated location-intelligent traffic notification service systems and methods
US6973384B2 (en) * 2001-12-06 2005-12-06 Bellsouth Intellectual Property Corporation Automated location-intelligent traffic notification service systems and methods
US20050288046A1 (en) * 2001-12-06 2005-12-29 Bellsouth Intellectual Property Corporation Automated location-intelligent traffic notification service systems and methods
US7430472B2 (en) * 2001-12-06 2008-09-30 At&T Intellectual Property L, L.P. Automated location-intelligent traffic notification service systems and methods
US7269505B2 (en) * 2001-12-06 2007-09-11 At&T Bls Intellectual Property, Inc. Automated location-intelligent traffic notification service systems and methods
US6845316B2 (en) * 2002-10-14 2005-01-18 Mytrafficnews.Com, Inc. Distribution of traffic and transit information
US20040143385A1 (en) * 2002-11-22 2004-07-22 Mobility Technologies Method of creating a virtual traffic network
US20050027437A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation, Device, system, method and program for notifying traffic condition and recording medium storing the program
US20050027448A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation Device, system, method and program for notifying traffic condition and recording medium storing such program
US20050027434A1 (en) * 2003-07-30 2005-02-03 Pioneer Corporation Information processing device, system thereof, method thereof, program thereof and recording medium storing such program
US7167795B2 (en) * 2003-07-30 2007-01-23 Pioneer Corporation Device, system, method and program for navigation and recording medium storing the program
US7266443B2 (en) * 2003-07-30 2007-09-04 Pioneer Corporation Information processing device, system thereof, method thereof, program thereof and recording medium storing such program
US20060055565A1 (en) * 2004-09-10 2006-03-16 Yukihiro Kawamata System and method for processing and displaying traffic information in an automotive navigation system
US20080109154A1 (en) * 2006-03-15 2008-05-08 Traffic.Com, Inc. Rating that represents the status along a specified driving route
US7203595B1 (en) * 2006-03-15 2007-04-10 Traffic.Com, Inc. Rating that represents the status along a specified driving route

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190113356A1 (en) * 2017-10-18 2019-04-18 Here Global B.V. Automatic discovery of optimal routes for flying cars and drones
US11692837B2 (en) * 2017-10-18 2023-07-04 Here Global B.V. Automatic discovery of optimal routes for flying cars and drones
US11035686B2 (en) 2018-08-31 2021-06-15 Here Global B.V. Use of geographic database comprising lane level information for traffic parameter prediction
US11669552B2 (en) 2018-08-31 2023-06-06 Here Global B.V. Use of geographic database comprising lane level information for traffic parameter prediction
EP3617651B1 (en) * 2018-08-31 2024-01-10 HERE Global B.V. Use of a geographic database comprising lane level information for traffic parameter prediction

Also Published As

Publication number Publication date
US7302341B1 (en) 2007-11-27
US7203595B1 (en) 2007-04-10
US8234056B2 (en) 2012-07-31
US20080109154A1 (en) 2008-05-08
US20070219707A1 (en) 2007-09-20

Similar Documents

Publication Publication Date Title
US8234056B2 (en) Rating that represents the status along a specified driving route
AU2016269536B2 (en) Systems, methods and interfaces for evaluating an online entity presence
CN103984762B (en) Content rendering control system and method
US8639575B2 (en) Audience segment estimation
Rossetti et al. I want to ride it where I like: Measuring design preferences in cycling infrastructure
US8494991B2 (en) Optimizing traffic predictions and enhancing notifications
US8918713B2 (en) Module specification for a module to be incorporated into a container document
US7610289B2 (en) System and method for monitoring and analyzing internet traffic
US20070136443A1 (en) Proxy server collection of data for module incorporation into a container document
US20100145947A1 (en) Method and apparatus for an inventive geo-network
US20070136201A1 (en) Customized container document modules using preferences
US20130304822A1 (en) Systems and Method for Displaying and Categorizing News Feed Posts
US20190095929A1 (en) Unification of web page reporting and updating through a page tag
US20130030987A1 (en) Paid Profile Personalization
JP2017517058A (en) A method for attaching to ads to calculate and automatically annotate prominence scores for phone numbers on web pages
CN101320369A (en) Method and system for inserting targeted data in available spaces of a webpage
US20070219938A1 (en) Attribute-Based Symbology Through Functional Styles
Kim et al. Roadside walking environments and major factors affecting pedestrian level of service
US20030041143A1 (en) Internet tool
Ferenchak et al. Equity analysis of proactively-vs. reactively-identified traffic safety issues
US7472169B2 (en) Method of displaying traffic information on a web page
Gitelman et al. An examination of billboard impacts on crashes on a suburban highway: Comparing three periods—Billboards present, removed, and restored
JP2006098888A (en) Communication network advertisement distribution program, communication network advertisement distribution system, and communication network advertisement distribution method
JP4461059B2 (en) Pseudo-push type information distribution system on the WWW
Vendivel Virtual rebel website: a strategy to increase user engagement through bounce rate analysis

Legal Events

Date Code Title Description
AS Assignment

Owner name: NAVTEQ B.V., NETHERLANDS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TRAFFIC.COM, INC.;REEL/FRAME:029108/0328

Effective date: 20120929

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION