Storing bus routes with bus stops

Resolved: Use route relations

Relations

Resolved

Relations are a good method to tag bus routes. Every information is taged only one time. If the name of the route change, this would be very easy to tag. Not every road or so. Bus routes should not be displayed in Mapnik or Osmarender. This would be too much information in the map to display. Like now (bus stops are displayed, routes not) it's good. Information about the routes may be on the bus stops. --Bahnpirat 06:11, 16 May 2008 (UTC)

Let's associate routes and roads with bus stops somehow, particularly if the suggestions about current use at Tag:highway=bus_stop are accurate and everybody decides that storing their location separate from the road is the right thing to do. The meaning of such an association would be that stops s1,s2,s3,...,sN serve route R which uses ways w1,w2,w3,...,wN. Or something like that anyway. --achadwick 10:35, 16 May 2008 (UTC)

Agreed. If bus stops are marked as points next to the road (as preferred now) and are included in a route relation, we have all the information we need without redundancy. The stop would not need any mandatory information to be of use (apart from a name), but could contain info about length of stop, availability of shelter and such. Serving bus lines could be kept in the relation only. Route changes would be easy. --Itschytoo 13:31, 24 June 2008 (UTC)

Where the bus service providing the route has a publication date, that should be included in the definition to aid updates when routes change. --Simon Arlott 11:53, 20 May 2008 (UTC)

Would it be worth creating a new tag to differentiate between bus numbers that are the same in different areas, for example region:uk_london or region:uk_surrey ? BlueSpecs 09:51, 15 June 2008 (UTC)

I'm using the network key for that; usually within a network, numbers/names aren't duplicated. --A uller 12:52, 11 September 2008 (UTC)

It might be preferred to put the bus stops near the road and not on it, but it might make it tricky for routing software. Is this problem solved or near a solution, or do we need to put the bus stop on the way so that routing software can recognise it as part of the bus route? If anyone knows of one routing software that recognises bus stops beside the road , please leave a message (in the free software kind , that is) Logictheo 09:07, 9 May 2009 (UTC)

All routers I've used can route to a point beside a road, leading to the point on the road but as near as possible to the destination. Routing on several transport methods would have to generate their routing graph anyway;

If the stops are not in the route relation, a bus+pedestrian routing needs to preprocess the data to find out where it's possible to hop on or off a bus, finding stops close enough to the route and checking that they are not closer to some other road.

If the stops next to the road are included in the route relation with appropriate roles, the preprocessing is trivial.

Experiment

Resolved

As an attempt to see how feasible this might be, with the aim of eventually doing some example renders, I'm taking a look at routes in my area. See Swansea/Buses for detail. Chriscf 15:39, 24 September 2008 (UTC)

Tagging loops

Resolved

What's the best way of tagging one way loops on a bus route - In Nottingham most bus routes use the local road network to turn around on rather than having a terminus - for example service 11 uses a loop taking in most of the city centre - hence around 10% of it's total route is only one way. At the moment I have plotted service 11 - to city 59496(XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx) as one route, but am unsure how to create the outbound loop - should it be an extension of the first, and if so how do I mark the extensions? What about the 44/45 which run the same route, one clockwise and one anti-clockwise with some differences in the centre. Finally is there best practice for saying this route is "green", "red", "purple" - Nottingham City Transport (and Trent Barton) brand their services (or collection of services) based on colour so it would be advantageous if any future map rendered the colours properly.

I use relations to tag bus routes. See 87924(XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx) for one example in Preston). On those ways where a route operates in only one direction, I tag the relation as 'forward' or 'backward' as appropriate to the direction of the way. Longwayround 08:42, 5 March 2009 (UTC)

Latest recommendation is to create one relation for each direction of the route. Alv 11:35, 24 August 2011 (BST)

Trolley wire

Resolved

Be aware that in various places in Europe trolley buses make use of the same electrical supply as trams, for instance on this bit of Hohlstrasse, Kreis 4, Zürich. This tag is apparently unused (OSMDoc, Tagwatch DE, GB). I suggest some further thought be given to this. It may well be a good to map as it is a conspicuous feature on the ground (keep along the street with overhead wires until ...). SK53 15:03, 20 August 2009 (UTC)

IMO a bus lane is a lane, and it should be included in the "total number of physical travel lanes making up the way" as lanes=* is described. A road that has two lanes in the "oneway direction" and one extra lane for psv's in the opposite, would be lanes=3lanes:forward=2lanes:psv:backward=1oneway:psv=no. Remind you, these lanes can in some places be open to all traffic at some times of the day (or night).

Good examples on making bus routes

I'm thinking it would be useful to have 'best examples' for each of the main ideas of making bus routes, so they can be set as an example on how to map bus routes. Logictheo 09:21, 8 May 2009 (UTC)

I've added an example image on the first page. It shows bus route ref:12 , and it has bus stops beside the road. This I think is one way of mapping bus routes. The other way which other people suggest is to put the bus stop on the road, to make it easier for routing software. If any of you wish you can add such an example (with image). Logictheo 14:16, 8 May 2009 (UTC)

Yes new people keep coming along and suggesting in-way nodes, but the most widely accepted approach is to put the bus stop off the edge of the way. Developers of routing software will need to make use of relations information to understand the related route. The bus stops would ideally be in the route relation, as in the example you've created an image of. In your image what do the blue and green lines mean though? - Harry Wood 09:58, 9 June 2009 (UTC)

Please put the highway=bus_stop on the way, highway=platform at the exact position of the bus stop sign / shelter. --Lulu-Ann 16:35, 10 June 2009 (UTC)

Why would the practice be changed? The bus_stop is at the sign/shelter, positioned most of the time as a node on the sidewalk, and the position on the way making up the road itself is (or apparently will be) public_transport=stop_position (as in User:Oxomoa/ÖPNV-Schema), if anyone's interested in adding such nodes. Alv 16:50, 10 June 2009 (UTC)

Good luck with trying to force a retagging. That proposal tries to redefine highway=bus_stop as the halt/stopping point, whereas it's been previously used as marking the quay... the platform is just a footway. Alv 17:30, 10 June 2009 (UTC)

Harry Wood, the green and blue lines are to highlight where the bus route is. It might not be easy to find the route so I tried to use a simple paint program to highlight, although now I know of a better way to highlight so I'll upload a new image soon. (using GIMP with paint transparency) logictheo 06:11, 15 May 2010 (UTC) ------------ Checking the openstreetbrowser status they will be back on Sunday maybe. logictheo 09:01, 15 May 2010 (UTC) ------------ Now I used an image based on mapnik and put it on the page. logictheo 11:01, 15 May 2010 (UTC)

I am trying to follow the public transport schema, but would like to put the name, number and stop id into the public_transport=stop_position nodes in the route relation. This is so that I can easily pull out the route from the map data, with all of the stop names and numbers. The bus stop is still placed on the map as a separate node, off the way, and it already contains these details as it appears to be imported from the local transport authority. Should I maybe just put a stop_id tag (reference) on the stop_position so that the other details can then be looked up from the bus stop node? PaulSchulz 30 Jul 2013

Classifying bus routes

Stale

I am starting to add some regional and country bus route relations around Nottingham. I would like to be able to discriminate between various categories of buses. For instance: ordinary urban/suburban services, country services (between villages), express commuter services (limited stop), regional services (between towns say within 50 km, but frequent stops) and national services. In many European countries this type of requirement is simply handled by assigning a network, but in the UK, where even within a town there may be 5-6 operators without any tariff union, this is not usually suitable.

Examples of each of my categories in the Nottingham area are: 1) urban - most services run by Nottingham City Transport; 2) local village buses - usually subsidised by the County Council under the Notts Bus scheme, but also various bus under the Connection name run by Trent-Barton; 3) commuter express : Red Arrow (Derby-Nottingham service), Bingham Express and Long Eaton Express; 4) Sherwood Sprinter and Fossway Flyer services between Nottingham and Newark, Pronto to Mansfield, TransPeak Nottingham-Derby-Matlock-Buxton-Stockport-Manchester; 5) national long distance routes, almost entirely run by National Express. This is a fairly crude typology, but it is analogous to the cycleway ncn-rcn-lcn hierarchy.

OpenStreetBrowser has a similar notion, but I'm not quite sure how it assigns transport route relations to its display categories. For instance all Zürich trams and buses are classified as suburban, but the Uetlibergbahn is classified as urban. In practice these are the wrong way round.

I can foresee in the future that transport maps may want to display less information for dense city networks, whereas routes between towns and villages can be shown at quite low zoom levels.

Other aspects of classification which I would like to consider in the future: service frequency (most useful as daytime), evening service or not, sunday service or not. In the UK most country and many regional services do not run on Sunday. SK53 20:30, 6 July 2009 (UTC)

Quite right: I think all these additional categories exist in the UK too (certainly factory, school, on demand, train replacement services + shopping buses (1 journey there-and-back once a week). However, I was hoping someone might tell me if there is any existing tagging scheme for any (or even all) of these categories. Your comment about not mapping some services suggests that there might be, but I have looked at data for several German cities and have not found anything similar to what I would like. SK53 13:47, 7 July 2009 (UTC)

With the growing number of bus lines in OSM, I think it is time to extend the tags for buses like it is suggested in the above User:Oxomoa discussion. There is a usable set of service and bus classification tags, which is essential to handle all bus lines of the world. Only with these, it is possible to create useful public transport maps, in which lines with high frequency are distinguished. --Vicuna 00:35, 17 May 2012 (BST)

OK. I miss the classification of bus routes (I called it "lines" above).

If I use www.öpnvkarte.de or the OSM Traffic Map then there are all bus routes on the same level. There are routes, that have a frequency of 10 mins, others are school routes on the countryside, which only are served twice a day. The more bus routes are included it is more important to see differences between them. On low zoom levels only the routes with high frequency should be displayed. Even on the maximum zoom level it should be possible to see, which routes have a good usability an which you should avoid.

To allow a separation in rendering, the basic information is needed. It can be useful to split up "regular" routes in "hourly or better" and "less then hourly". It is not necessary to include the timetable, but a classification is IMHO very important. The standard classifications should be given for choice in Potlatch, JOSM, etc. If I missed the things I'm talking about, please tell me. --Vicuna 00:58, 26 May 2012 (BST)

Major cleanup of page

Following a discussion on talk-transit we are giving all the public transport related article a bit of a tidy-up to help new people get to understand how it hangs together better. If you are offended by any edits then people either discuss it here or preferably on talk-transit. PeterIto 08:36, 7 August 2009 (UTC)

Lines, routes and services - which term to use?

Should we call a bus service offered to the public a 'Bus Route', a 'Bus Line' or a 'Bus Service? Currently we are using all terms interchagably. For example these is a section called 'Bus Services' which then says that they should be defined using as a 'Route' relation. Some people use the 'Line' relation for this purpose (as proposed by Oxomoa). This Buses:talk page also uses the term Line in the section 'Classifying Bus Routes' for the same term. This can be confusing and I suggest we try to use one term throughout. Transmodel (and therefore the EU professional community) have settled on Line; Route being used to describe the physical path taken by a vehicle through the infrastructure. I don't mind what we use, but we should be consistent. Personally sticking to Route seems to make sense to me, Line comes second and Service as my least favourite (because it can mean so many think); the 'Saturday service' (runs of Saturday), the bus is 'in service' today (it is being used operationally at the moment) and... the bus is 'being serviced' today (ie it is being repaired and is not available). Any comments? PeterIto 17:09, 9 August 2009 (UTC)

Oh, and I have just noticed that on the Public transport page we talk about 'Service Routes'. PeterIto 17:11, 9 August 2009 (UTC)

Busway tag

The page introduce key:busway, but the wiki page starts saying "PLEASE NOTE that there was no formal proposal for this feature and it is not well established (and probably will never be well established because of the inconsistencies it creates). In parts this page contradicts the current OSM data model. You are NOT encouraged to use this!". I would propose to add the same sentence in this page as well. --FabC 13:12, 7 December 2011 (UTC)

Inconsistency for route_master tagging

Relation:route master says to tag relations of type=route_master with route_master=train/bus/... The Buses page says to use route=bus/route=trolleybus also for route_master relations. I propose to change the Buses page to use the convention from Relation:route master.

Depending of national and/or regional definitions a bus stop is not always the same. Therefore I do write a overall definition of a bus stop here. For me a bus stop is everything that belongs to the infrastructure (Pole, Platform, yellow ziczac-line, ...). I would therefore define a bus stop as the stop-area-relation. But as I said before, this is my personal point of view. --Teddych 06:58, 8 July 2012 (BST)

Thanks so much Teddych!!! I was really confused about the 'public transport schema' and didn't really understand the tags that were introduced. David. S 10:52, 9 July 2012 (BST)

Hi, I was wondering if the platform which is just a node (to mark the pole) is going to be rendered, if so, when? Thanks! David. S 12:14, 9 July 2012 (BST)

I'm surprised, because I thought that in earlier days platform nodes have been rendered correctly... --Teddych 13:59, 9 July 2012 (BST)

Mapping alternative lineflow

How do you map a busline that (partly) has two different lines to travel. Alternating one hour between ways A-B-C-D and the other hour ways A-E-F-D. Can this be done in the same relation but a different role for the alternate ways or does this have to be a second relation?
Mdeen 10:26, 24 November 2012 (UTC)

Please use different relations. That is the cleanest way to express it. This is even less work than a mixed relation, because you can copy the common part between the relations. -- Roland 2012-11-24 14h07 UTC

Using multiple relations is a bad idea: if the "common" part of many route variants gets changed, you have to manually change each of the variant relations individually. With 20+ variations (in my case), this is a disaster for maintainability. -- mwbg 2013-10-04T21:35

Hail & Ride sections

Is there any agreed way to add a Hail & Ride section to a route relation? By this I mean a road either with no bus stop flags/signs, or where these are purely indicative or timing points, on which you can flag down a bus at any safe point (as you would with a taxi)? --CunningPlanWhat's on your mind? 10:20, 13 February 2013 (UTC)

Probably not. I've been wondering about this myself and haven't found any common schema. If you were to apply the existing notation creatively, you might come up with something like type=site + public_transport=stop_position, where these tags are applied to a relation which contains all the ways that are part of the hail and ride section. You could then treat this site relation as any other bus stop and add it to your route relation with role stop. But however you choose to tag these hail and ride sections, it's probably best to leave a note explaining what exactly your novel tagging schema means, so as to avoid confusion.

Edit: Another way I can think of is using roles like forward:hail_and_ride and backward:hail_and_ride (or hail_and_ride if you're using bidirectional relations) for ways in the route relation. —Joemppe (talk) 08:32, 20 February 2013 (UTC)

Intermediate Terminuses, Short-runnings, Alternative Routings

I am mapping buses in my (rural) area and am trying to do, as recommended, one relation per route-variant (and per direction).

It is very difficult for me to stick to this one-relation-per-variant model, as there are so many variants.

1.
The route starts at the bus station and proceeds to the next town. However, some of the journeys (not a minority) start in a suburb, before proceeding to the bus station.

2.
On the way, a shopping centre is sometimes served, and sometimes not (sometimes on-demand)

3.
The route generally ends with a one-way trip into a big housing estate.
Short-runnings are common, with at least two more timetabled terminating points (so it never gets to the BHE above).
One of the short-runnings can end its trip at one of two bus-stops (near to each other, but an uphill walk between) depending
on where the bus is diagrammed to go next.

4.
The return journey (out of the BHE) follows what amounts to a continuation of a big one-way loop, after a wait. For some people, this is still the outward journey.

5.
Different timetables can put the same trip terminating at different points.

Through tickets are generally available.

All the above has one number. There are lettered variants available, but these variants are minor compared to variants _within_ the service.

Looking at the timetable, there are at least twenty possible trip patterns. I really don't want to have to do twenty variants, especially as they would all have the same number.

Does anyone have any idea how to handle this ?

We should remove this big messy list "Buses by city" and promote usage of Template:PlaceFeature template and "Category: FEATURE in ABC" structure