IMHO route_ref is just a placeholder until you make the stops members of the route relations, so don't worry about it
Richard On Wed, Jul 21, 2010 at 3:35 PM, Hillsman, Edward <hills...@cutr.usf.edu> wrote: > As I mentioned in an earlier post, we have two public transit systems > operating in the area of our university. They both serve a transit > center/bus_station just off campus, but they share some stops on campus (and > pass by some of the others’ stops on campus). They have multiple routes at > some of the shared stops. > > > > I have found guidance on the wiki > (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop) that where a > multiple routes serve a stop, this should be tagged by listing the routes in > numeric order and then (if necessary) alphabetical order, with the routes > separated by semicolons, using no spaces unless they are part of the route > designation. The example in the wiki is > > > > route_ref=66A;123;456;s78;x9 > > > > What is not clear is how to handle a situation in which a stop serves two > operators and multiple routes for each. For example, one stop is on HART > routes 5 and 12, and on USF routes A and C > > > > By inference, we would code the operators in alphabetical order, separated > by semicolons, as > > > > operator=HART;USF > > > > And in this case, because the USF system designates routes by letters while > HART uses numbers, we could luck out with > > > > route_ref=5;12;A;D > > > > But if both systems used route numbers, this would not indicate which routes > belong to which operators. > > > > I know from experience that transit agencies in the Puget Sound region > interline all the time, sometimes at transit centers/bus_stations but more > often not, and most use numeric route identifiers. My understanding is that > when the UK privatized some of its bus service, it had multiple companies > serving the same stops. So this should not be a one-off instance here. > > > > An alternative format would be to code an operator1=HART and > route_ref1=5;12, and an operator2=USF with route_ref2=A;D, but this seems > error-prone to me. I’ve seen this format used in mapping some other > features, but I haven’t seen documentation of it. > > > > A recent comment here suggested that it might be better not to include route > information, because routes change, and situations such as this may be > another reason not to do so. However, the routes near campus are very stable > (the USF system adds routes, but otherwise changes them only to avoid > construction). And, when we communicated with local mappers of bus_stops > about our plans to upload GTFS data, we were asked whether we could upload > the routes as well as the other information. So there is demand for it, even > though in a trip-planning application we would use the GTFS stop_id to link > between other OSM data and transit route/schedule data. > > > > We would welcome suggestions or guidance on how to handle the route tagging. > Given the specialized focus of this problem, I’m not posting it to the > tagging listserv. > > > > Ed > > > > 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
