During the past month or so, the members of this listserv have had some discussion of importing bus stops in GTFS format into OSM and the use of relations to group such data. Several members have expressed reluctance to get involved in creating a full set of route relations (i.e., bus stops plus street paths for the actual travel path of the bus) and maintaining those relations in OSM when large public transportation agencies change routes with a fair amount of frequency. And our experience and that of others on the listserv is that these GTFS bus stop datasets contain some locational errors and ambiguities that complicate creating the street path portions of the relations, especially by automated means..
It seems there are several possible uses of the stop and route information in OSM, and these need different types of data: 1) Electronic Map - The visual electronic equivalent of a paper map, which someone can consult to see where the bus routes go, or find which bus route might serve a destination. This probably would be most effective if the map could display the linear route (including the direction of travel) for the reader, rather than just the bus stops. Lines order the stop data, even if the stops are not displayed. 2) Generating trip information - Finding "trip paths" between an origin and a destination, using only OSM data for streets, sidewalks, transit routes, etc., and then displaying the resulting path of the trip overlaid on the map. Most likely, the algorithm that identifies the pathway for the journey would benefit from knowing the sequence as well as the locations of the stops, and again the linear route through the street network would be valuable for this. 3) Generating trip information, with transit exception - Similar to the second application above, it stores bus stop locations in OSM and uses OSM data for walking and biking directions, but it uses route and schedule data contained in the GTFS file (and not stored within OSM), for transit directions. The two sets of trips then are linked using bus stop location information from the GTFS dataset. This is the approach taken by OpenTripPlanner.org. OpenTripPlanner uses OSM sidewalk, street, etc. data to generate biking and walking trips, but uses GTFS datasets to generate transit trips. Ultimately, because OSM is not designed to store the detailed timetable data needed to plan trips at different times on different days, some reference to timetable and route data outside of OSM will be necessary for cases #1 and #2 above, even if OSM is perfectly good for the supporting infrastructure (which I believe it generally is). While it would certainly be good to have the stop sequence (i.e., route path) recorded in OSM, to support all three of these uses, creating and maintaining this is potentially a lot of work, and for some applications it is not necessary. Plus, there is the problem that route path relations seem to be easy to break and hard for beginning mappers to maintain. On the other hand, it is actually pretty simple and straightforward to create a relation for each of a transit agency's routes, and to put just the stops into the proper relations when importing or updating them. So, would there be anything wrong with putting only the stops into route relations, without trying to figure out and code route paths as part of that relation? The only negative we can see is that the route path part of the relation would not exist, and so the data would not support the use cases #1 and #2 for transit. OpenTripPlanner appears to be a very popular routing engine which is available in many geographic areas. Thus, for a software tool we're developing we're leaning towards not including transit route information within OSM per case #3. As with anything in OSM, individuals map what they know or are interested in, and may ignore or omit features that they are not interested in. Someone who comes along later and decides that the route paths are really important could code them into the route relations. Are there other applications that might require a representation of the path for use cases #1 and #2 above, that we should be considering? Edward L. Hillsman, Ph.D. Senior Research Associate Center for Urban Transportation Research University of South Florida 4202 Fowler Ave., CUT100 Tampa, FL 33620-5375 813-974-2977 (tel) 813-974-5168 (fax) [email protected] http://www.cutr.usf.edu<blocked::http://www.cutr.usf.edu/>
_______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
