Taking this a bit further there is a blog that talks about displaying routes on a map, the last example on the page has a route number on it which might be useful. www.gravitystorm.co.uk/shine/archives/2008/05/29/look-ma-no-hands/
Cheerio John On 16 August 2010 14:52, Hillsman, Edward <hills...@cutr.usf.edu> wrote: > 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) > > hills...@cutr.usf.edu > > http://www.cutr.usf.edu > > > > _______________________________________________ > Talk-transit mailing list > Talk-transit@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-transit > > _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
