Methods and devices for providing route information

This application claims priority under 35 U.S.C. 119(e) to U.S. provisional application Ser. No. 60/715,077 filed Sep. 8, 2005.

Transit visualization systems ('TVS″) provide updated graphical information relating to the positions of a vehicle or other targets (e.g., luggage or parcels) along a route. This type of information may be used by transit operators, shipping companies, government entities, and universities to track the progress and location of a target. In one example, the target is a mass transit vehicle. Therefore, the location and expected arrival time of a shuttle at a predetermined stop along a route can be seen on a TVS display. Some systems display a map that includes routes for the target and a graphical representation of the target position along the route. Given that the TVS display provides updated target positions, various advantages may be provided by a TVS, including reduced wait times for passengers, improved safety, and improved customer satisfaction.

The success of a TVS may depend upon several factors that include displaying true real time tracking information and displaying this information in an uncluttered, easily recognizable manner. In order to appeal to a broad customer base, a TVS display may provide route and position information for many targets. Several disadvantages arise as the amount of information that is displayed increases. First, a TVS display map may become cluttered with information that is not relevant to each user. Second, the amount of information that must be transmitted to successfully display all target route and position information increases. The ability of a TVS to display real time target information for tracked targets is subject to bandwidth limitations. Therefore, transmitting and displaying all target information on a TVS display may not be an optimal solution.

Embodiments disclosed herein are directed to the optimization of information that is transmitted and displayed in a TVS. Route information for a plurality of routes may be displayed using display indicators assigned to each route. The routes may be decomposed into discrete segments, some of which are shared among the routes. Upon determining which segments are shared by routes, the shared segments may be displayed using an interleaved pattern of the display indicators associated with the routes. The interleaved patterns may be created based upon a visibility state for routes that share the segment. Thus, in one embodiment, the interleaved pattern is created using display indicators for visible routes. The interleaved pattern may comprise an alternating pattern of the display indicators associated with the routes. Non-shared segments may be displayed with the respective display indicators for the routes that use that segment. The width of the interleaved patterns may be substantially the same as the width of the non-shared segments. In one embodiment, the routes may be fixed. Targets associated with each route may be displayed on the routes.

FIG. 1 is a functional block diagram of a transit visualization system according to one embodiment;

FIG. 2 is an exemplary transit map illustrating routes, segments, and targets according to one embodiment;

FIG. 3 is a functional block diagram of an exemplary tracking server to track and render target information according to one embodiment;

FIG. 4 is a series of mapped segments illustrating an interleaved pattern for shared route segments according to one embodiment;

FIG. 5 is a flow diagram illustrating various software level process steps executed to render an interleaved pattern according to one embodiment;

FIG. 6 is a functional block diagram illustrating a scheme for disseminating route visibility information according to one embodiment;

FIG. 7 is a functional block diagram illustrating a scheme for disseminating route visibility information according to one embodiment;

FIG. 8 is a functional block diagram illustrating a scheme for disseminating route visibility information according to one embodiment; and

FIG. 9 is a functional block diagram illustrating a scheme for disseminating route visibility information according to one embodiment.

The various embodiments disclosed herein are applicable in a transit visualization system (“TVS”) that provides updated graphical information relating to the positions of one or more targets along a route. A representative TVS is illustrated in FIG. 1 and is identified generally by reference number 10 . Generally, one characteristic function of the TVS 10 is to provide updated graphical information related to the position of a target 12 to users on displays 14 . The TVS 10 may be used to track the position of different types of targets 12 . For example, the target 12 may be a package, a component on an assembly line, or a transit vehicle such as a bus, shuttle, ferry, subway, trolley, taxi, and the like.

Target 12 tracking may be provided using a number of technologies. In one embodiment, a Global Positioning System (“GPS”) tracking system is used. GPS uses a network of satellites 16 to triangulate the position of a receiver and provide position coordinates. To that end, the target 12 may be provided with a GPS receiver device 18 that works in conjunction with the satellites 16 to determine a current position (often in terms of a latitude and longitude coordinate set) for the target 12 . The current position of the target 12 is updated within the GPS receiver device 18 through communications with the satellites 16 .

Other means of determining the position of the target 12 may be used. For instance, assisted GPS (A-GPS) and Television assisted GPS (TV-GPS) offer possible alternative technologies that may be used to track the target 12 . A-GPS describes a system where outside sources, such as an assistance server (Mobile Location Server) coupled to a network, help a GPS receiver 18 execute range measurements and determine the target 12 position. TV-GPS is a system that combines television signals with GPS technology for tracking targets 12 in places where GPS alone is inadequate, such as between high-rise buildings of urban centers or inside buildings and garages. Other technologies that do not rely on satellite 16 technology may also be used. For instance, accelerometers may be used to calculate distances traveled based upon time and acceleration values. Another similar technique uses dead reckoning as a process of estimating a global position of the target 12 by advancing a known position using course, speed, time and distance traveled. In one embodiment, the tracking in instantaneous and continually updated.

In an alternative embodiment, the target 12 may be equipped with a tracking device that permits location tracking using a more passive approach. For instance, the target 12 may comprise a node, button, or tag, such as an RFID tags that may be tracked by a geographic information system.

Regardless of the method used to determine a current position, data representative of the position of the target 12 can be transmitted to a tracking server 22 . In one embodiment, the target 12 is provided with a mobile communications device 20 that permits data transmission to and from a communications station 24 . In one embodiment, the mobile communications device 20 is able to send transmissions but not receive transmissions. The communications station 24 may comprise a transceiver (e.g., tower) 26 and a base station 28 . The base station 28 comprises the necessary hardware/software to convert the received wireless data (which may be cellular, circuit switched, or packet switched data) to a suitable data protocol for transmission over a network 30 such as the Internet.

The position data is received by a tracking server 22 . The tracking server 22 processes the received position data for one or more targets 12 and presents the position data that is accessible by remote client displays 14 . In one embodiment, the position data is provided in the form of a web page that is accessible by clients associated with each display 14 . The displays 14 may be embodied in a variety of device types. For instance, the display 14 may be a computer monitor for desktop, laptop, and handheld computer devices. The display 14 may be a dedicated monitor provided in the form of a kiosk that continually shows the updated target 12 position data. Alternatively, the display 14 may be an LCD display on a wireless communications handset such as a PDA, Blackberry, cellular telephone, pager, or the like.

For these different display 14 types, the target 12 position data may be presented in the form of a map. FIG. 2 shows an exemplary map that may be presented on the displays 14 . In this example, the map includes three different routes identified as R 1 , R 2 , and R 3 . Further, three separate targets T 1 , T 2 , T 3 are shown at various locations along these routes R 1 , R 2 , R 3 . In addition, each route R 1 , R 2 , R 3 is divided into segments. For example, route R 1 is divided into the segments A, B, C, D, and E. The segments are used by the tracking server 22 to render the maps and track the position of the targets T 1 , T 2 , T 3 in a manner that is described in greater detail below. The segment labels (e.g., A, B, C, etc.) may not be important to the end users and may or may not be shown on the display 14 . However, the segment labels are illustrated in FIG. 2 to demonstrate the route generation and rendering processes described herein.

FIG. 3 illustrates a functional block diagram illustrating various aspects of the tracking server 22 that generates the position map shown in FIG. 2 . Generally, the tracking server 22 performs at least four broad functions. These include a target controller 32 , a target motion analyzer 34 , a route controller 36 , and a renderer 38 . The target controller 32 is responsible for receiving and tracking position data for multiple targets 12 . Thus, the target controller 32 receives data that is transmitted by the mobile communications device 20 associated with each target 12 . The content and frequency of the data transmissions between the mobile communications device 20 and the target controller 32 are optimized to minimize bandwidth and improve the rate at which the position of the target 12 is updated.

In one embodiment, the frequency of transmission from the mobile communications device 20 and the target controller 32 is based upon the distance moved by the target 12 . For instance, if the target 12 does not move, the mobile communications device 20 does not transmit any position data. Similarly, the frequency of transmission from the mobile communications device 20 and the target controller 32 may be based upon the speed of target 12 . That is, at slower speeds, the position data is transmitted less frequently since the position of the target 12 changes relatively little. Conversely, at higher target 12 speeds, the position of the target 12 changes at a greater rate. Therefore, the position data is transmitted more frequently at greater target 12 speeds.

The content of data transmissions between the mobile communications device 20 and the target controller 32 may also be optimized to improve data throughput. For instance, various lossless compression algorithms, including run length encoding, entropy encoding, and linear predictive encoding may be used to reduce the time that is required to update the position of the target 12 . Lossy compression algorithms may also be implemented depending upon the relative resolution of the position data and the amount of lost data. In addition, the position data may be minimized by transmitting only position differences.

As an example, if the latitude and longitude readings for a target 12 in a first position are (35.77247, −78.69340), each of these coordinate values may require at least a 26-bit digital representation to identify the current position of the target 12 . Now, assuming the target 12 moves to a second position identified by the coordinates (35.77454, −78.68903), the same amount of data (i.e., about 26 bits per coordinate) might need to be transmitted to identify the updated position of the target 12 . However, the amount of data that is transmitted by the mobile communications device 20 may be reduced if the difference between these coordinate positions (i.e., −0.00207, −0.00437) is transmitted instead of the actual position. In one embodiment, only the significant numbers in this difference data are transmitted. For instance, in the present example, only the numbers 207 and 437 (or a digital representation thereof) are transmitted. Thus, the amount of data that is transmitted may be reduced to about 8 or 10 bits per coordinate. In an alternative embodiment, a fixed number of least significant bits representative of the difference data is transmitted. The actual position of the target 12 may be recreated by the target controller 32 using the position difference data and the last known coordinate position.

To the extent any compression processing is performed on the data prior to transmission by the mobile communications device 20 , the target 12 may be configured with a mobile computer 19 . That is, data compression and position difference calculations may be performed by the mobile computer 19 before the compressed data is transmitted by the mobile communications device 20 . The compressed data may be decoded upon receipt by the target controller 32 .

Referring to FIG. 3 , the tracking server 22 may also be configured with a target motion analyzer 34 that analyzes position information for one or more targets 12 that is received and/or decoded by the target controller 32 . The target motion analyzer 34 considers prior target positions, current target positions, and expected target positions (based at least partly upon a predetermined route) to smooth and correct a graphical position for the one or more targets 12 . For example, the target motion analyzer 34 performs velocity and acceleration calculations to confirm that a target 12 remains on a predetermined route. In one embodiment, the target motion analyzer 34 may snap a target position onto a predetermined route if the received target position varies from an expected position by a value that falls within a predetermined range. By snapping the target to the predetermined route, small position errors such as communications errors or data compression errors can be filtered, thus providing smooth target 12 motion at the displays 14 . In one embodiment, the target motion analyzer 34 may recognize that a target position has deviated from a predetermined route if the received target position varies from an expected position by a value that exceeds a predetermined range. In this case, the target motion analyzer 34 may not snap the target position back to the predetermined route.

The exemplary tracking server 22 shown in FIG. 3 also includes a route controller 36 that determines one or more predetermined routes along which a target 12 may travel. The route controller 36 may also determine whether a given route should be enabled or disabled. In one embodiment, the status of a route may be determined at the terminal 14 by a consumer. In this manner, the customer may choose to display those routes that are relevant to that user or that location. In one embodiment, the route controller 36 may disable a route if the signal quality for communications from a mobile communications device 20 degrades. Thus, if a communications signal becomes weak, dirty, or disappears completely, the route controller 36 may disable the route corresponding to the target 12 that has the poor incoming signal.

As described above, the routes may be comprised of a collection of segments as illustrated in FIG. 2 . For example, the three routes R 1 , R 2 , R 3 shown in FIG. 2 are respectively comprised of the following segments:

R 1 : A, B, C, D, E R 2 : D, F, G R 3 : C, D, F, H, J, K, L

With these particular routes R 1 , R 2 , R 3 , certain segments are shared. For instance, segment D is common to all three routes R 1 , R 2 , R 3 . That is, targets T 1 , T 2 , T 3 each travel along segment D at some point in their respective routes R 1 , R 2 , R 3 . Note also that segment C is common to routes R 1 and R 3 . In one embodiment, segments are identified as portions of streets and may be represented by lists of coordinate pairs. The segments may be further defined by additional criteria in the interest of rendering segments in an interleaved pattern.

For example, there may be no routes that only cover a portion of the segment. Stated another way, all routes sharing a segment share the entire segment. Further, the segments are mutually exclusive. That is, no portion of the segment overlaps another segment. Representing routes as segmented data satisfying these requirements has several benefits. On the one hand, it ensures that segments used by multiple routes are only defined once instead of for each route. Further, it also provides a simplified mechanism for identifying segments that are shared by multiple routes. Accordingly, the segments, so defined, allow an interleaved pattern representing multiple routes for a given segment to be determined.

Examples of route interleaving over a shared segment are illustrated in FIG. 4 , where three instances of the segments C, D, and G (from FIG. 2 ) are shown. In the map regions illustrated in FIG. 4 , the routes are identified by display indicators. In this embodiment, the display indicators are shapes XX, OO, and ΔΔ. This type of route identification may be advantageous for monochrome displays. The same effect may be achieved through the use of color display indicators, particular where full color displays 14 are available. In other applications, such as for handicap-accessible applications or colorblind-accessible applications, other techniques for identifying routes may be used. For instance, routes may be associated with different fill or hatch patterns. In either case, the route interleaving generates a segment having route identifying symbols arranged along the segment in an alternating fashion. Alternatively, a list of route names or numbers may be rendered next to a segment to identify the routes that are using that segment. For each of these solutions, the highlighted segment may be rendered with a consistent thickness as opposed to multiple, parallel pathways. In one embodiment, the interleaved segments are comprised of side by side display indicators.

In the first map shown on the left side of FIG. 4 , the first route R 1 is enabled while the other two routes R 2 , R 3 are disabled. Consequently, markers XX representing the first route are shown in segments C, D. In the second map shown at the center of FIG. 4 , the first two routes R 1 , R 2 are enabled, but the third route R 3 remains disabled. Consequently, the markers XX and OO corresponding to routes R 1 and R 2 are shown. As suggested above, segment D is shared between routes R 1 and R 2 . Therefore, the markers XX and OO are interleaved over the length of segment D. By comparison, only markers XX appear over segment C and markers OO appear over segment G.

In the third map shown on the right side of FIG. 4 , all three routes R 1 , R 2 , R 3 are enabled. Consequently, all markers XX, OO, and ΔΔ corresponding to routes R 1 , R 2 , R 3 are shown. Notably, segment G is not shared. Thus, only the markers OO corresponding to route R 2 are shown over this segment G. By comparison, segment C is shared between routes R 1 and R 3 . Therefore, markers XX and Δγ are interleaved over the length of segment C. Also, segment D is shared between all three routes R 1 , R 2 , R 3 . Therefore, markers XX, OO, and ΔΔ are interleaved over the length of segment D.

The route interleaving may be performed by a renderer 38 in the tracking server 22 as shown in FIG. 2 . The renderer 38 may interact with the route controller 36 to determine the position and status of the various routes and route segments. The renderer 38 may also determine from the route controller 36 which routes are shared at a given segment. The renderer 38 may also interact with the target motion analyzer 34 to generate a moving icon representative of the position of a target 12 along the highlighted routes.

In at least one embodiment, the renderer 38 also has access to a map database 40 as illustrated in FIG. 3 . Thus, in addition to a null space, where routes and targets are rendered in a stand-alone context, the routes may be overlaid onto a map comprising geographic and architectural information. The renderer 38 may also generate graphics representative of street names or other labels, such as shuttle stops, corresponding to predetermined locations along a route.

The various routes and segments, including interleaved segments, may be created as software objects at either the level of the tracking server 22 or the display 14 . The overall process is depicted in the flow diagram illustrated in FIG. 5 . The software objects may be created with the information defined by the aforementioned route definition process. That is, in step 500 , the overall transit network is decomposed into a sequence of segments using one or more of the characteristics described above. Then, individual routes are defined in step 502 as a segment list that is comprised of all segments a target 12 will traverse in following a route.

Once these items are defined, a segment object is created in step 504 for each segment in the network. Similarly, a route object is created in step 506 for each route. If a segment is used to define a route, that segment object is added to the route object's list of segments in step 508 . Similarly, that route object is added in step 510 to the segment object's list of routes. Thus, there is an interrelation between one or more segment objects and route objects. Formally stated, a route object RO i is created in software for each actual route R i , and a segment object SO j is created in software for each actual segment S j . Then, for each RO i and SO j , SO j is added to RO i 's list of segments if a segment S j is within a given route R i . Also, RO i is added to SO j 's list of Routes if that segment S j is within the route R i .

With access to the route objects that make use of it, a segment object is able to check the visibility state of a route object and thereby determine whether that route object's display indicator should be included in the interleaved pattern. Thus, if a user elects to make a certain route visible, the pattern or color associated with that route will be used in building the interleaved pattern in step 512 . The interleaved pattern may be constructed from a compiled list of patterns or colors associated with the visible route objects that use it. The segment object is then rendered to the display as a series of lines connecting its points. In one embodiment, each pattern or color is used to draw the segment object for a given distance before changing to the next pattern or color in the sequence. The patterns or colors can be cycled as needed until the full length of the segment object is rendered.

Subsequently, the route network, including all interleaved and non-interleaved segments are made available for the various displays 14 in step 514 . While the route display status remains unchanged (e.g., route visibility remains the same), the route network provided in step 514 remains the same. However, if the route visibility changes as identified by the YES path in decision step 516 , the one or more route objects that change are able to notify its constituent segment objects of this change. As a result, the segment objects rebuild the interleaved pattern in step 512 according to the updated route visibility. Then, the updated route network, including the updated interleaved segments, are made available for the various displays 14 in step 514 .

In embodiments discussed above, a plurality of route objects and segment objects are interrelated as depicted in FIG. 6 . As described above, the segment objects SO 1 -SO 4 have a knowledge of routes used by those segments and route objects RO 1 -RO 2 have a knowledge of segments that make up those routes. In the embodiment shown, routes identified by RO 1 and RO 2 share segments identified by SO 2 and SO 3 . Consequently, information regarding route visibility changes and the display changes that are caused by such changes may be disseminated through the interrelated communications scheme shown.

With this scheme, various techniques may be used to notify segment objects SO 1 -SO 4 of visibility changes. In one embodiment, the route objects RO 1 -RO 2 notify segment objects SO 1 -SO 4 of the precise nature of the visibility change that occurs. For instance, the segment objects SO 1 -SO 4 are notified when route object RO 1 or RO 2 changes from ON to OFF or OFF to ON. In one embodiment, the route objects RO 1 -RO 2 notify segments that this visibility change has occurred and the segments then render a shared pattern including only display indicators for visible routes that use the shared segments. In this embodiment, the route objects RO 1 -RO 2 may notify only those segment objects SO 1 -SO 4 that make up the route. In FIG. 6 , route object RO 1 notifies SO 1 -SO 3 and route object RO 2 notifies SO 2 -SO 4 . Alternatively, the route objects RO 1 -RO 2 may notify all segments. Upon receiving the updated visibility information, all segment objects SO 1 -SO 4 may be rendered again. Alternatively, only those segment objects SO 1 -SO 4 affected by the visibility change are rendered again.

In an alternative embodiment, the route objects RO 1 -RO 2 merely notify the segment objects SO 1 -SO 4 that there has been a change in visibility status (not the precise nature of the change). At this point, the segment objects SO 1 -SO 4 may poll route objects RO 1 -RO 2 using that segment to determine if a change is indicated. As above, the route objects RO 1 -RO 2 may notify all segment objects SO 1 -SO 4 or only those segment objects SO 1 -SO 4 used by a given route.

FIG. 7 shows an alternative embodiment where the route visibility information is centrally stored and accessible by all segment objects SO 1 -SO 4 . The route visibility information may be stored in a table, registry, or memory location and accessible through pointers. In this embodiment, the segment objects SO 1 -SO 4 may receive a general notification that visibility change for one or more routes has occurred. The segment objects SO 1 -SO 4 may then access the route visibility information to determine if a given segment needs to be redrawn.

FIG. 8 shows a slightly different embodiment where the route visibility information is again centrally stored. However, in this embodiment, the segment objects SO 1 -SO 4 periodically poll the information to determine if there have been any changes. Segments are then redrawn when a change in the route visibility is detected. In an alternative embodiment, the segment objects SO 1 -SO 2 may periodically poll route objects RO 1 -RO 2 (as in FIG. 6 ) to determine if there have been any visibility changes.

FIG. 9 shows an alternative embodiment similar to FIG. 8 except that the visibility information is limited to shared routes. Thus, only segment objects SO 2 , SO 3 , which are the only shared segments in the present example, access the shared route visibility information. These segments SO 2 , SO 3 periodically poll the information to determine if there have been any changes. These segments are then redrawn when a change in the route visibility is detected.

The present invention may be carried out in other specific ways than those herein set forth without departing from the scope and essential characteristics of the invention. For example, certain embodiments described above have contemplated a dynamic rendering process where interleaving is performed on the fly. Another possibility is when a network of transit routes is fairly static (e.g., routes do not vary significantly for extended periods). In these cases, it may be appropriate to define the segments once, and store them is some intermediate representation, so that they can be retrieved whenever route visualization is required. This intermediate representation could most likely be a computer file and could be stored locally or transferred over a network when a viewing session is initiated. The later case may be beneficial in web-based client/server situations where automatic updates of route data are required.

Furthermore, while various embodiments have related to public transportation networks and routes used by vehicles, other embodiments could be applied to communication networks and networks in general where multiple routes share paths. For example, circuit networks, HVAC networks, assembly lines, and the sort may benefit from the teachings described herein. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.