[Talk-transit] [Talk-gb-westmidlands] Bus operator references

Andy Robinson (blackadder-lists) ajrlists at googlemail.com
Wed Jul 1 17:49:09 BST 2009

Peter Miller wrote:
>Sent: 01 July 2009 4:18 PM
>To: Andy Robinson (blackadder-lists)
>Cc: osm; Talk-gb-westmidlands at openstreetmap.org
>Subject: Re: [Talk-gb-westmidlands] Bus operator references
>On 1 Jul 2009, at 14:43, Andy Robinson (blackadder-lists) wrote:
>> I'm a bit confused by what are the correct bus operator references
>> in west
>> mids.
>> For example, Brian is using NXWM for National Express West Midlands
>> which
>> would seem logical, however on the Centro website if I check at the
>> bottom
>> of a route number page I find that WMT is still referenced on all the
>> timetables and operator code given as WMT not NXWM.
>Do be aware that two or more bus operators can share a route, often
>with one running during the busy periods as a commercial service and
>another being paid under contract to run services at quieter times
>(evenings and weekends for example). Also be aware that you are using
>the term 'route' to cover all the roads that a service with a
>particular service number uses. In Transmodel it is refined a bit with
>a number of different terms. It would make the professional community
>very happy, and might work better in the longer term for OSM to
>reflect on their modelling and terminology for a few minutes. In the
>following text I will use Capitalised words for Transmodel concepts.
>In Transmodel a Line is a thing with a pubic facing code (ie 11C, 71,
>105 etc) - so what you call a route is what Transmodel calls a Line.
>Transmodel uses the term Route to mean a unique ambiguous path through
>the transport infrastructure (road or rail) taken in whole or part by
>a vehicle operating on a Line. There will normally be two or more
>Routes per Line (in opposite directions for starters and then possibly
>various detours). At some point we are going to want this information
>in addition to the correct collected data in the route relations.
>It then defines a Service Pattern as a unique sequence of Stop Points
>that a vehicle calls at while it goes along a Route (it may not stop
>at all Stop Points it passes on the route). There can be more that one
>Service Pattern for one Route, normally due to short working.
>Timing Patterns are defined giving the interval of time between Stop
>Points and are associated with a Service Pattern. There can be more
>that one Timing Pattern per Service Pattern. In the rush hour more
>time is allowed for completion of the route than during off-peak times.
>Vehicle Journeys then run on a Timing Pattern (which have an
>associated Service Pattern and hence Route and Line) at particular
>times. Each Vehicle Journey is associated with an operator (allowing a
>Line to be shared between multiple operators). The Vehicle Journey
>only needs a start time, set of days and data range and Timing Pattern
>and everything else can be worked out from the Timing Pattern and
>associated Service pattern and Line. It is pretty clever general and
>normalises out repetitive data (such as Service Pattern and Route)
>while allowing all situations to be accommodated.
>Sorry for the rant / brain-dump, but it is something that I have
>wanted to raise for a while now. It may be useful to use the Route
>relations to mean what Transmodel means by a Route (a unique path
>through the network) and then wrap those Route relations up into a
>Line Relation.
>Anyway, something to think about.

Nothing to stop someone adding separate relations for each service and
indeed I think its likely we will go that way where there is confusion. Its
easier to make two relations than to try and understand multiple services.
For now it's a case of one step at a time though. The vast majority of folks
will never get as far as Brian, Christoph and I if its any more complicated
than it already is anyway, in fact its probably too complicated already when
you consider overlapping relations. So, maybe over to the transport
professionals to add the stuff they might want separately?

The "route" relation has been in standing since relations came about, so its
unlikely we will see it give way to an alternative naming method (eg line),
but I agree it may become confusing when routing algorithm routes are
different to relation routes. Mostly though I think we generally understand
the context differences, so unlikely there is an issue within OSM. Easy
enough to add a transmodel=line tag anyway if that's needed.



>> Any ideas, I think this crops up with other operators too.
>> Cheers
>> Andy
>> _______________________________________________
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

More information about the Talk-transit mailing list