Online Traffic Information Systems
Review Summary

plaisant@cs.umd.edu

We focused our search on sites that present traffic information visually on a map, focusing on speed data but also making notes about special aspects of camera and accident detail data when of interest . Sites mentioned in this report include: Phoenix, Atlanta, San Antonio, San Diego, Los Angeles, Minneapolis, Paris - France, Belgium, Rotterdam -Netherlands, Madrid – Spain, Toronto - Canada, and Athens – Greece, as well as other sites in a smaller way. Maryland was not included here because we are all already familiar with this site. Sites encountered during the search that didn’t seem particularly different from what was already found were not included.

All sites provide speed information, but only few give times. One example is Paris where times between main beltway exits (or between exits and airports) are given on the map itself after some zooming had taken place. Atlanta has a separate table for travel times, and the information can also be found by probing all the DMSs. Athens seems to have an experiment in progress to look at how people want to see travel times on maps. Madrid Spain seems to give density of traffic not speed – even though of course it is probably calculated from the speeds. I don’t recall seeing any display of past data but only current status. In Paris trends are indicated on the message signs (in the form of increasing or decreasing markers for the travel times)

Some sites have 2 colors only (fluid vs. not), others use a continuous range (e.g. white to red in Rotterdam). Most North America sites use red-green and variations with 4 or 5 colors. Selecting colors is a challenge! One common problem is the selection of a color that stands out too much for the areas without data. It is preferable to use a muted color to avoid attracting attention to those areas. If many colors are used a good legend is important, and it is preferable to lay it out to match the up/down order of the speeds (instead of left right).

Red-orange-green is a natural set of colors for this application because of the natural red=stop, green=go convention. Nevertheless red-green combinations can cause problems for colorblind users. None of the sites seem to address that question in an explicit manner. Even though my son is color blind, as was my dad, I cannot predict what colors will be easy to recognize... Of course user testing with colorblind users will help, but then you are faced with differences in color monitors and graphic cards, brightness makes a difference etc. Remember also that some colors that seem very close/similar to "normal" i.e. non color-blind users may be completely dissimilar to others, so picking an ordered set of 4 or 5 colors is even harder than just 3 colors.

If you choose the red-green direction, which is a natural for transportation maps, it will be important to test the colors, but the only way to be safe is to provide a way for users to change the colors. This could be done by either providing 2 or 3 sets of color combinations including one without color at all (only a scale of one color) for users completely color blind. An alternative is to give users a palette and let them select colors, but that would be annoying for a web application without some kind of registration and user profile, and could only considered for potential color-blind operators.

I suggest that you locate the messages of any people who complained about color so we could test a new set of colors with them.

Atlanta shows a good example of showing a combination of sensor/point data for areas with less sensors and link data for areas with good sensor coverage. Making user aware of the size of the link may be useful. For example San Antonio or Minneapolis do a good job showing the size of each small link, making clear what the unit is. The choice of using point versus link display depend of the resolution of the map. For example the Los Angeles map shows data at the sensor location only, but LA is so large that the sensors appear very close to each other on the map, providing an apparent continuity.

Not all sites provide cameras, far from it.

The main problem with the cameras is that usually one cannot tell what way they are facing. Sometime a title/direction is given, but not always, and it is difficult to decide if those names can be trusted. The position on the icon on the map can makes a big difference on what guess users will make as to the position of the camera itself and its possible orientations. But I think CHART use of "saved directions/points" for the cameras will make a big difference in usability since save points can have descriptive descriptions the public can understand.

Static images versus video.

Because users don’t always have the right plug-in or the time to wait for the video, showing static images is a more practical solution than showing video. A compromise might be to start with a static image (with time stamp) and offer video on demand with a extra button selection.

Other options to the orientation problem: Phoenix gives for each camera a link to a page showing possible views of the roadway from that camera, and lets users figure out where the current view is pointing to. Toronto gives a written explanation, which is possible because the cameras are located at consistent locations along the highway.

For me the worse problem was that in some cases there was no indication of the incidents on the speed data map! One had to select a different view to see the accidents.

Accidents detail messages are not always clear (e.g. what is high impact? Or what is time to clean up? Is it that the road has to be swept? Does that include clean up of the congestion?) The position of the icon on the map is important, a blowup would be great but I didn’t see it anywhere. Showing an history of the recent past incidents is helpful to review what may have been causing the congestion now, or to explain why a person is late. In a few instance I also saw road word data, but there was so much data to look at I gave up. For the general public it seems that only the major road work likely to create congestion should be indicated.

Several decent examples of message presentation (e.g. Atlanta). One typical problem is that the icons on the map do not make clear if the sign has a message of not, so one has to probe all icons to see where there are messages. Atlanta also allows the review of a whole set of messages at once for a highway section. It was hard to find but a direct pointer to that page would be useful for a commuter using the road section everyday.

Some sites provides links to alternative transportation from merely a link to another website to providing comparison of travel time between cars and public transportation (e.g. in Paris). Special maps are provided for special destinations (e.g. airports) with special travel time calculations. In one occasion a diagram is given to show the overall traffic volume over the course of the day, giving a good indication of the timing and duration of the rush periods.

In most cases the zooming is by step and special zones are created to allow zooming. One site (Belgium) used Java to give a smooth zooming map but of course it is longer to load.

In appendix are notes about websites, links and many screen samples. Because color printer are not very good... the documents are available online at http://www.cs.umd.edu/hcil/highway/review

Web Accessibility