[Tagging] tagging bus stops served by more than one public transportation agency

[Ed Hillsman]

Hi

A few weeks ago, I posted the following question to talk-transit  
(edited here slightly from the original post, based on the limited  
feedback received there). Given the specialized focus of the problem,  
I did not post it to the tagging listserv, but I had very limited  
response to the question on talk-transit, so I'm posting it here, but  
from a slightly different perspective.

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. This situation is not the norm in the US, but it is not  
uncommon either, and I understand it is not uncommon elsewhere either.

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

This is pretty clear, and it is in a place where inquiring new mappers  
are highly likely to find it, so we want to follow this practice. 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;C

But if both systems used route numbers, this would not indicate which  
routes belong to which operators.

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 a few times in  
mapping some other features, but I haven't seen documentation of it.  
The response from talk-transit that directly responded to the question  
offered a third suggestion (which the mapper says he uses), which is  
to code the transit agency operator into the tag for the routes. So,  
in this example,

operator=HART;USF
hart_route_ref=5;12
usf_route_ref=A;C

By extension, either this or the operator1/operator2 approach would  
apply if other tags differ between the operators who serve a given  
stop (e.g., name1/name1, or hart_name/usf_name, and yes, the two  
agencies do use different names for some of the stops they share).

A recent comment on talk-transit suggested that it might be better not  
to include route information, because routes change, and situations  
such as the one I am asking about 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 stop data from a local transit agency that has given  
permission to do so, 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 an identifier in  
the stop data in OSM to link between other OSM data and transit route/ 
schedule data outside of OSM.

We would welcome suggestions or guidance on how to handle the route  
tagging with multiple operators. I think we will simply have to pick a  
scheme and go with it (and document it on the wiki). But it would be  
helpful to know whether any of these is more likely or less likely to  
make it easier or harder to work with the the data within OSM, or  
whether any of these is more consistent, or less consistent, with  
widely-agreed practices. This is the perspective I've added from the  
original post.

Ed Hillsman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20100729/d61eb70c/attachment-0001.html>