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
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
