|
ScheduleViewer
The schedule_viewer application for exploring a feed on a map
IntroductionSchedule Viewer is a Python program for viewing the contents of a Google Transit Feed Spec feed on a map. It's a diagnostic program intended for those creating a feed, and as such doesn't include trip planning or other features that are useful to transit riders. InstallationThe Schedule Viewer is part of the Transit Feed Distribution. See the page about the transit feed distribution for instructions on installing either the Windows executable or python source. To run you need:
Running from sourcepython schedule_viewer.py [--key <google_maps_api_key>] --feed_filename <feed_file_or_directory> On Windows the python executable is normally installed as C:\Python25\python Running Windows exeIf you installed the Windows exe run the following command schedule_viewer.exe [--key <google_maps_api_key>] --feed_filename <feed_file_or_directory> If you run it from Start -> Run include the full path of schedule_viewer.exe and if you are in a command prompt change into the directory containing schedule_viewer.exe. Explore your dataOnce schedule_viewer has finished loading the feed file it prints a URL. Ignore that URL because it won't work with your Google Maps API key. Instead go to http://localhost:8765/ in your web browser and a page similar to the screen shot above should load. Exploring stopsAfter you drag the map to a new location with your mouse it will display stops in the current area as semi-transparent blue markers. Multiple stops at the same location will stack up making a darker blue marker. If stops.txt defines location_type attribute to distinguish between stations and stops, the stations have red markers and stops have blue ones. Note that the FeedValidator warns that stops within 2m of each other should be merged. If there are lots of stops in the map area only a sample will be displayed. To see all the stops you need to zoom in. The map zooms in when double clicked. If you click on a marker it opens a window listing the "stop_name (stop_id)" and the next trips to visit the stop after "Time:" (HH:MM at top left of screen). If the stop_times table doesn't contain an exact time for a trip the viewer interpolates a time and displays it with a ~. Click on a trip to display it (See "Viewing a trip").
The "Find Station:" field (top left of window) will search for all stops that have a name or stop_id containing the string you enter. The stops will be displayed in yellow. If there is a single match the station's info window will open. If there are multiple matches you may need to zoom out to see them all. Exploring routesThe left pane lists all the routes in the feed. Click on one of the route names to see the trip patterns (a group of trips that visit the same stops in the same order) for that route. Gray background of pattern indicates that it has a trip with non-zero trip_type value (an unusual trip). The first trip will automatically be selected, and shown on the map. For each trip pattern the number of stops, number of trips and start times are displayed. For patterns that have many trips only a few start times are displayed. To see the start times of more trips edit "Time:" (HH:MM at top left of screen) and click on the route name again. Viewing a tripAfter you click on a trip in a stop marker's window or on a start time in the route list it is displayed in the map. Every stop of the trip is shown as a yellow marker. A semi-transparent blue marker (See "Exploring stops") on top of a yellow looks gray. Timepoints have the time displayed on the map. Some of the source data for that trip and route will be displayed at the bottom of the window. Below the source data is a Marey Graph (CRI, Timetables people and Tufte and Graphical Timetables for BART).
The Marey Graph shows all the trips with the same pattern as the selected trip. Different colors representing different service periods (See issue 79). Time increases to the right with a scale in hours since midnight at the top. The distance between stops is on the Y axis but not labeled. A steeper line represents faster movement. In the screen shot above you can see fairly fast service with stops far apart in the East Bay, followed by a big gap without stops in the tunnel under the bay, followed by frequent stops in the city of San Francisco. If you place your mouse over a trip it is selected in white and the trip_id appears below the graph. You see a single service id provides the only service, at a constant headway, until about 9am. Inspecting for problemsWhen you first load the schedule viewer the map is zoomed out to contain all stops. If this is much larger than your service area there is probably a stop in the wrong place. Move the service are out of displayed map area and the distant stop will probably appear. Check the location of a stop by zooming in until you can see the street names. Click on the stop marker to open the window and make sure the marker is in the correct location. For rail stations you may see the real location more easily with satellite view. Repeat this for stops in different parts of the service area. Click through all the routes. In each route look at one trip of each pattern. Watch out for unreasonably fast or slow legs. If the polyline has any jumps there may be a stop with the incorrect geo location or incorrect information in the stop_times table. If the agency has published a route map it can help you confirm that the trip in GTFS is correct. Here are some examples of buggy data:
A stop with a bad geo location in stops.txt or using the wrong stop_id in stop_times.txt can cause a big jump. Big jumps also stick out as a very fast (almost vertical) line in the Marey Graph. Note that a route with a long express section may look similar in the Marey Graph.
A zig-zag can be caused by bad geo locations in stops.txt or an incorrect sequence of stop_id values in stop_times.txt.
Someone familiar with BART may notice that this skips two stops. Bugs and feature requestsVote for known ScheduleViewer issues so the developers know what is important. If you find an unreported bug or have a feature request please file a new issue and add the label App-ScheduleViewer. |
Sign in to add a comment
Can you explain color and fading of pins? I notice some pins are faded and the colors yellow, grey, blue.
Can you explain the time and stop search functionality?
I added explanation of pins on top of each other. Search for Time: on this page. I expanded the Find Station explanation.
I can not load Scheduler Viewer. Can you explain step by step?
tjbaumler: this doc is an attempt at explaining. what did you try? how did it fail? Copy-and-paste of errors or screenshots can help.
Hi, I am also having problems loading the Schedule_Viewe? r. Being I run a BSD environment I load it from source, and I keep getting a syntax error response. This is the exact response I received from the tty window: From running python schedule_viewer.py:
SyntaxError?: invalid syntaxFrom running python feedvalidator.py: Traceback (most recent call last):
SyntaxError?: invalid syntaxAny thoughts on how to rectify this? I'm not a Python programmer, so I'm honestly not sure how to proceed. These are the details of my current platform: OS: Mac OS X v10.4.11 Build 8S2167 Kernel: Darwin 8.11.1
Do you have an intel Mac?
If so I would suggest using a program like parallels and running the windows version
I my self am a mac user and i had trouble getting python to work.....
i used the windows version of schedule viewer and its a lot easier to figure out
Hello, I'm having problems running schedule_viewer.exe and feedvalidator.exe. I have installed Python 2.5 twice. I also have Pyton2.4 on the machine. I'm getting the following message:
C:\Transit>feedvalidator.exe LoadLibrary?(pythondll) failedThe specified module could not be found. C:\Transit\PYTHON25.DLL C:\Transit>schedule_viewer.exe LoadLibrary?(pythondll) failedThe specified module could not be found. C:\Transit\PYTHON25.DLL C:\Transit>
any help would be greatly appreciated
App-ScheduleViewer
We have a stop where bus arrives at one time (7:02) and waits to depart at another time (7:10). I think we have our data correctly. But schedule viewer approximates the stop times for the next stop (7:03) seems to be based on the arrive time of this previous stop instead of the depart time.