U.S. patent application number 11/888035 was filed with the patent office on 2007-12-27 for rating that represents the status along a specified driving route.
Invention is credited to Gregory A. Auxer, James F. Carroll, Brian J. Smyth.
Application Number | 20070299602 11/888035 |
Document ID | / |
Family ID | 37904301 |
Filed Date | 2007-12-27 |
United States Patent
Application |
20070299602 |
Kind Code |
A1 |
Auxer; Gregory A. ; et
al. |
December 27, 2007 |
Rating that represents the status along a specified driving
route
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.
Inventors: |
Auxer; Gregory A.;
(Glenmore, PA) ; Carroll; James F.;
(Gilbertsivlle, PA) ; Smyth; Brian J.; (West
Chester, PA) |
Correspondence
Address: |
NAVTEQ NORTH AMERICA, LLC
425 West RANDOLPH STREET
SUITE 1200, PATENT DEPT
CHICAGO
IL
60606
US
|
Family ID: |
37904301 |
Appl. No.: |
11/888035 |
Filed: |
July 31, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11703442 |
Feb 7, 2007 |
|
|
|
11888035 |
Jul 31, 2007 |
|
|
|
11376731 |
Mar 15, 2006 |
7203595 |
|
|
11703442 |
Feb 7, 2007 |
|
|
|
Current U.S.
Class: |
701/533 |
Current CPC
Class: |
G08G 1/0104 20130101;
G06Q 30/00 20130101; G01C 21/3691 20130101; G01C 21/26
20130101 |
Class at
Publication: |
701/202 |
International
Class: |
G01C 21/34 20060101
G01C021/34 |
Claims
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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
[0004] 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.
[0005] In the drawings:
[0006] FIG. 1 shows generic examples of Jam Factors for various
traffic situations.
[0007] FIG. 2 shows specific examples of Jam Factors for the
commute segment I-76 from the PA Turnpike to the Walt Whitman
Bridge.
[0008] FIG. 3a shows the user interface display screen for
selecting a drive name and metro (metropolitan) area.
[0009] FIG. 3b shows the user interface display screen for
selecting a starting roadway.
[0010] FIG. 3c shows the user interface display screen for
selecting start and end points on starting road.
[0011] FIG. 3d shows the user interface display screen for
selecting a continuation to a connecting roadway.
[0012] FIG. 3e shows the user interface display screen for
selecting to end a commute.
[0013] FIG. 3f shows the user interface display screen for viewing
drives and overall Jam Factor for those drives.
[0014] FIG. 3g 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.
[0015] FIG. 4a shows the Magnet Product Page which a user will see
when they first access the magnet website (or are not logged
in).
[0016] FIG. 4b shows a screenshot of the pages of the Traffic
Magnet registration page where user information is entered.
[0017] FIG. 4c shows a screenshot of the Traffic Magnet
registration page that displays the User Agreement and Privacy
Policy.
[0018] FIG. 4d shows an example of a magnet on the maintenance
page.
[0019] FIG. 4e shows a screenshot of the magnet creation page where
user information is entered.
[0020] FIG. 4f shows a screenshot of the magnet creation page where
the format of the magnet is selected.
[0021] FIG. 5 shows examples of the layouts of a horizontal magnet
and a vertical magnet.
[0022] FIG. 6 shows some of the different styles of magnets
available to the user.
[0023] FIG. 7 shows the database schema for the Traffic Magnet
data.
[0024] FIG. 8 shows a Data Flow Diagram for the user interface for
the creation of a Traffic Magnet.
DETAILED DESCRIPTION OF THE INVENTION
[0025] 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.
[0026] The present invention is described in the context of two
services, namely, TrafficMagnets.TM. and Jam Factor.TM. 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
[0027] 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).
[0028] 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.
[0029] 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:
[0030] 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
##EQU1## 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:
[0031] 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:
[0032] 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 ##EQU2## FreeFlowTT = CongItemLength RouteSpeedLimit
##EQU2.2## CongestionDelay = i = 1 .English Pound. .times.
congitems .times. .times. ( CongestionTT i - FreeFlowTT i )
##EQU2.3## TABLE-US-00001 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:
[0033] 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 .English Pound. .times. .times. items .times. .times. ( Delay
i ) ##EQU3##
[0034] The following table may be used to map the criticalities of
incidents to an estimated delay. TABLE-US-00002 TABLE 2 Criticality
Delays: Criticality Delay (min) 0 20 1 10 2 5 3 2
3. Jam Factor:
[0035] 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 ##EQU4## where .times. : ##EQU4.2##
FreeFlowTT = KR_Length SpeedLimit ##EQU4.3##
[0036] 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.
[0037] Below is a table of delay multiples with expected Jam
Factors. TABLE-US-00003 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
[0038] 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): [0039] prev=point preceding the
actual delay multiple [0040] next=point following the actual delay
multiple JamFactor = JamFactor next - JamFactor prev DelayMultiple
next - DelayMultiple prev * ( DelayMultiple actual - DelayMultiple
next ) + JamFactor next ##EQU5##
[0041] FIG. 1 shows generic examples of Jam Factors for various
traffic situations.
[0042] FIG. 2 shows specific examples of Jam Factors for the
commute segment I-76 from the PA Turnpike to the Walt Whitman
Bridge.
[0043] III. Creating and Viewing a Jam Factor Rating
[0044] FIGS. 3a through 3g 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.
[0045] FIG. 3a shows the user interface display screen for
selecting a drive name and metropolitan area.
[0046] FIG. 3b shows the user interface display screen for
selecting a starting roadway.
[0047] FIG. 3c shows the user interface display screen for
selecting start and end points on starting road.
[0048] FIG. 3d shows the user interface display screen for
selecting a continuation to a connecting roadway.
[0049] FIG. 3e shows the user interface display screen for
selecting to end a commute.
[0050] FIG. 3f shows the user interface display screen for viewing
drives and overall Jam Factor for those drives.
V. Specifications for a Traffic Magnet
[0051] 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
[0052] The user interface for creating traffic magnets is
preferably web based, and located at http://magnet.traffic.com.
[0053] FIG. 4a 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
[0054] FIGS. 4b and 4c show the registration page. The following
data will be requested from the user: TABLE-US-00004 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.
[0055] 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.
[0056] After the user successfully creates an account, they can
then log into the system with their newly created username and
password.
[0057] FIG. 3g 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
[0058] 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.
[0059] 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).
[0060] 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.
[0061] 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.
[0062] 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
[0063] FIG. 4d 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
[0064] 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.times.285
horizontal, 200.times.605 vertical).
[0065] 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-US-00005 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
[0066] 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-US-00006 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
[0067] 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.)
[0068] FIGS. 4e and 4f 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-US-00007 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
[0069] 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.
[0070] d. Traffic Magnet Creation Use Cases TABLE-US-00008 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
[0071] TABLE-US-00009 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
[0072] TABLE-US-00010 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
[0073] 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
[0074] FIG. 5 shows examples of the layouts of a horizontal magnet
and a vertical magnet.
b. Magnet Content
[0075] 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
[0076] Roadway Shield (if applicable to the road)--Four different
shield types (U.S. state, interstate, county) with the road number
overlaid on top. [0077] 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. [0078] Jam
Factor--Visual representation of route conditions, equating to a
number between 0 and 10. [0079] 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
[0080] 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.
[0081] 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).
[0082] 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.
[0083] i. Route Information Generation
[0084] 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-directio-
n>. The text in between "<>" is text that is replaced by
real data during processing.
[0085] 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.
[0086] 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.
[0087] ii. Magnet Information Generation
[0088] 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: [0089] Magnet is created
[0090] Magnet is deleted [0091] Route changes are made to the
system, affecting specific route ID's [0092] Design for a style
changes [0093] Magnet html for a metro changes.
[0094] 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.
[0095] 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.
[0096] 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
[0097] 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
[0098] FIG. 8 shows a Data Flow Diagram for the user interface. The
steps in the diagram are explained as follows:
[0099] 10. User specifically types in or is directed to the
magnet.traffic.com domain
[0100] 20. The application checks if there are any browser cookies
available which specify that the user has already logged in.
[0101] 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).
[0102] 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).
[0103] 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).
[0104] 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.
[0105] 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).
[0106] 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).
[0107] 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.
[0108] 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.
[0109] 90. If a user has forgotten their password, they can enter
their username on this form and receive an email containing their
password.
[0110] 100. The user can login from the home page by entering their
username and password into the proper fields.
[0111] 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
[0112] 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-US-00011 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
[0113] TABLE-US-00012 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
[0114] TABLE-US-00013 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)
[0115] 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.
[0116] 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.
[0117] 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.
[0118] 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.
* * * * *
References