So I understand that the correct way to tag a bus service route relation is to add the to: and from: tag, and its also proposed to use via: when applicable. So I am facing this dilemma where a bus physically goes from bus stop name "Mjøndalen" to "Bragernes torg", via "Ytterkollen". But on the actual bus it doesnt say that, instead it say "Drammen via Ytterkollen". "Drammen" being the city where bus stop "Bragernes torg" is. So what is the correct name to tag with on to: and from:? --Ascaaear (talk) 09:23, 29 April 2017 (UTC)
- I would use the place displayed on the destination plate, timetable, directory, etc., for the from and to tags. -Miklcct (talk) 11:46, 29 April 2017 (UTC)
Storing bus routes with bus stops
- Thanks Miklcct for the clarification. I'll make an edit to the page to make it more obvious that this is the appropriate key to differentiate between weekend and weekday routes. IanVG (talk) 15:18, 13 November 2021 (UTC)
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.
- What case is meant with "recognizes bus stops beside the road"? Alv 10:42, 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;
Names of bus_stop(s)
Usually every bus_stop has it's own name. However I was not able to find any suggestion about using some property to type names. Could we use "name" for this? --User:Zajec, 13:10, September 9, 2008
- I've been doing this, and it seems to work OK even if it isn't rendered right now. Sometimes they have two names though (... two different bus companies...). --achadwick 12:31, 11 September 2008 (UTC)
Depots are places where buses are stored overnight or when otherwise not in use. They may be used for refuelling or repairs.
Depots are not amenity=bus_stations so amenity=bus_depot seems useful. --LeedsTracker 01:17, 17 September 2008 (UTC)
- Hardly an amenity as in serving the public; more of a private industrial area. amenity=parking + access=private + landuse=industrial/commercial + fenced=yes? Fuel stations within with similar access restrictions. Alv 06:35, 17 September 2008 (UTC)
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)
- Relations for bus route following this sheme are not experimental any more. See Hannover/Transportation and Map of public transportation --Lulu-Ann 10:05, 5 March 2009 (UTC)
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 cityas 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 Longwayround 08:42, 5 March 2009 (UTC) 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.
- Latest recommendation is to create one relation for each direction of the route. Alv 11:35, 24 August 2011 (BST)
- So if I understand it correct, when tagging a bus loop using the exact same road back and forth, we should still make two separate relations? Can someone please explain how to tag the direction and differentiate between the two relations when the two share the exact same road? --Ascaaear (talk) 07:27, 24 April 2017 (UTC)
- Sorry for being a bit unclear - I know how to tag the loop. My point is, how would people/apps know the difference between those two relations? If the routes is exact similar, I know it doesnt matter, but if the second route has a slightly different route - is there a way to tag it to show the direction the bus use? I have cases where a bus use two-direction roads, but the bus itself only drive it in one direction, and then a different road on the way back. --Ascaaear (talk) 16:13, 24 April 2017 (UTC)
- The tagging of loop lines and non-loop lines are different. If the line is a loop line, by definition it starts and ends at the same terminus, simply add all the ways to the relation in the correct order from the terminus to the same terminus. If after looping the bus uses the exact same ways return, then all ways are added into the relation twice - once before the loop, once after the loop.
- Check the following bus line as an example:
- This is a loop time which loops at the north end, and the forward and return routes are nearly the same - you can see that the whole Route Twisk is added two times into the relation, from south to north and then from north to south. However, there are some one way roads (including dual carriageways) at the southern part of the route, which is added in the appropriate direction only.
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)
Contra-flow bus lanes
Some roads have contra-flow bus lanes where any traffic can travel in one direction but only buses may travel in the other. How should we deal with these? Longwayround 08:45, 5 March 2009 (UTC)
- I would tag it similar to contra-flow cycle lanes: oneway=yes psv=opposite_lane --Cartinus 02:16, 31 March 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=3 lanes:forward=2 lanes:psv:backward=1 oneway:psv=no. Remind you, these lanes can in some places be open to all traffic at some times of the day (or night).
- So far there's 317 uses of psv=opposite_lane (and 19 of bus=opposite_lane), with 315 uses of lanes:psv=* and several of each of the various forms like lanes:bus:forward=*. Alv 11:48, 24 August 2011 (BST)
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
- Another Data Point - See: http://www.overpass-api.de/public_transport.html which uses the Overpass API to generate public transport line diagrams. In order to get the stop names to appear in the diagram I need to put the name in the node used in the relation (stop_position). I'm not sure if this is correct or not. PaulSchulz 1 Aug 2013
Classifying bus routes
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)
- You forgot to distinguish the following bus lines (in Germany):
- regular bus lines (urban/interurban/international)
- train-replacing bus lines (temporary service, but somebody may want to map them)
- peak-time bus lines
- factory bus lines (rush-hour only)
- school bus lines (no service during vacation)
- bus on demand (call 1 hour before departure)
- So far, I didn't map school buses and buses on demand because there is no opportunity to map them separately from regular lines.
- --FK270673 22:12, 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)
Currently there are no valid bus classifications. We should try to suggest some bus classifications (by editing the following wiki page) BEFORE they are going to create a new renderer: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Bus_lines_and_trolley_bus_lines
- --FK270673 20:06, 8 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)
- The Oxomoa-Schema has been extended and is now called Public Transport-Schema and has been approved in 2011-04-20. --Teddych 12:08, 21 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)
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)
- key:busway has no formal proposal. In contrast to that the Public Transport Schema, including buses, has been approved at 2011-04-20. --Teddych 14:07, 7 July 2012 (BST)
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.
- Fixed. --Teddych 14:02, 7 July 2012 (BST)
Relations for bus stops
- No. But you should add the stop position and the platform to the route relation. --Teddych 13:50, 7 July 2012 (BST)
- Hi, what is the difference between bus stops and stop positions? For the bus stops I have created, I have used the tags 'bus_stop=yes', 'public_transport=stop_position', 'bus=yes' and so on. I'll give a image. http://b.tile2.opencyclemap.org/transport/18/236469/160922.png
- public_transport=stop_position has to be placed ON the street as a node where the bus stops on the street. public_transport=platform is BESIDE the street (as node, way or area) where the passengers are waiting.
- 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)
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)? --CunningPlan What'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
 - this category should be generated automatically when somebody uses PlaceFeature template with 3 parameters: 1. map feature 2. country 3. city 4. locality in city (optional)
Different bus use, route variants...
I am working on rendering my region's bus network. After adding several lines, I wondered how to distinguish school buses, main or less important buses, times (peak hours only vs 24/24 or day-only...) and different variant (some line maps split routes in "main","secondary",and "occasionnal". But I couldn't find any proposal for this (except a few tags like passenger). I am thinking of a new way to show a bus route details :
- passenger=* (who the line is dedicated to) = [current accepted values] + school....
- working_hours=* (approximate hours for limited values) = peak (morning & evening), day, day_and_night, night_only (yes I do know night_only tag)...
- importance=main for main buses in a specific network
- servicing_type=* (not sure of the name...) = "main","secondary","occasionnal"...
(I also have the problems highligted in "Intermediate Terminuses, Short-runnings, Alternative Routings" section above) PS : I'm french, so you might disagree with the name I give to tags and values... sorry --Clementrouxosm (talk) 14:07, 27 December 2017 (UTC)
- I use opening_hours=* for the actual operating hours (e.g. 06:00 - 23:30) on the timetable -Miklcct (talk) 14:43, 27 December 2017 (UTC)
- Please take a look at my proposal and the respective talk page about a standardized way to differentiate public transport routes. --Ialokim (talk) 20:08, 5 January 2018 (UTC)
Under Step 2, "Adding streets to the relation": It first says all streets have to have the role "platform" but in the next paragraph says any roles for streets are invalid. Which is correct? Fredlyfish4 (talk) 12:35, 12 October 2018 (UTC)
- Streets should have no role. This was corrected on 20 Oct. Johnparis (talk) 22:36, 13 February 2019 (UTC)
- The "route master" is a super-relation; that is, it consists only of other relations (the different variants of the route itself). Therefore there is no concept of a "where" for a route master. The easiest way I know for the "how" is via JOSM. Simply select the two (or more) route relations and create a single (new) route_master relation with the route relations as members. It can probably be done in iD or Potlatch but I don't know how. Johnparis (talk) 22:39, 13 February 2019 (UTC)
Bus Route changes based on day
- Create two routes with the same ref with different opening_hours=* --Miklcct (talk) 14:38, 17 December 2020 (UTC)
stop_position & platorm
- The stop positions are optional and usually not necessary. But it's useful to include the bus stops in the relation. --Jeisenbe (talk) 06:31, 18 August 2019 (UTC)
Bus Route Naming
Hi all, I am hesitant to follow the guidelines for (master) route relation naming for a couple of reasons:
1) The guidelines for naming individual routes asks for redundant information: if I already have ref, to, from, then I don't really need to add a name that can be constructed from those elements. 2) Similar for the master route relation, simply calling it `Bus X` is redundant, since there would already be a ref as well that can be used to construct this.
I would much rather: 1) leave name empty for the individual relations 2) Use the official route name for the master relation name tag
Does that make sense?
- If I'm not mistaken, the idea behind that guideline was to make route relations discernible whenever an editor or a changeset page on osm.org displays a list of relations. Aside from the redundancy you mentioned, it seems like a curious exception to the usual guidelines around name=*. For this one feature type only, we're told to use a name tag to describe the feature. It amounts to tagging for the editor, because the whole value never appears in reality, not with this
=>syntax at least. These days, some editors have different ways of making relations discernible in a list: for example, in the absence of a name=*, iD displays the network=* and ref=*. It would be trivial for iD to also display the to=* and from=*, similar to the suggested format. So I would personally be comfortable with using name=* the normal way for route relations too. – Minh Nguyễn 💬 06:31, 22 August 2020 (UTC)
- Yes, it is a clear case of Tagging for the renderer (in this case renderer in the editor) and should be avoided Mateusz Konieczny (talk) 20:18, 22 August 2020 (UTC)
- It has led to Nominatim ignoring names of route relations. As such it could be worth a campaign to clean up existing relations. --Andrew (talk) 19:42, 24 August 2020 (UTC)
I've marked the relevant passages as controversial, directing readers to this discussion, to avoid confusion about the authoritativeness of that oft-criticized portion of the public transport schema.  – Minh Nguyễn 💬 03:45, 22 February 2022 (UTC)
Should turnaround loops be marked somehow in bus routes?
Should loops that are not travelled by passengers (being between last exit and first entry) be marked somehow when drawing bus routes? For example, over here all the bus routes on Kaptol Street turn around on the quasi-roundabout. But this part is after the last exit ("Kaptol - izlaz putnika") and before the first entry ("Kaptol Peron 3"), so no passengers going in either direction will be in the vehicle. However it seems incomplete to me to leave this loop out, especially since it's a stretch of road dedicated solely to buses turning around. Rostaman (talk) 10:54, 17 December 2020 (UTC)
- No, the loop is not part of the bus route. Please don't add it into either direction. -Miklcct (talk) 14:37, 17 December 2020 (UTC)
Maintenance of Bus Routes
Just curious, how is the maintenance of bus routes managed over time? Is it done manually, or are there tools to validate a bus route or a nifty Overpass Turbo query that can parse whether, how and where a bus route is broken? I feel like I’ve heard that the German based OSM community has had a go at maintaining these kinds of relations. —IanVG (talk) 03:50, 17 September 2021 (UTC)
- It depends on location as availability and format of usable sources differs. In some places it is simply not maintained at all Mateusz Konieczny (talk) 11:05, 18 September 2021 (UTC)
Last Segment of Bus Route
Although it may be obvious to some people, I think it would be great to explicitly cover this part of the process. "The last segment is the street/road/way that is traversed by the bus immediately before and not including the first segment of the journey if the bus route is a loop." Might need some word-smithing, but does that make sense to some people here? IanVG (talk) 02:09, 9 November 2021 (UTC)
click the plus symbol near the bottom under
Should we 'repair' after splitting?
- 'You may need to split the street to only select the part of it that is covered by the bus route.
After we have done all our splitting and made our relation, shouldn't we come back and somehow "repair" the "damage"? I mean this road has now been split by us into 15 different segments.
- No, it's necessary to distinguish different routes. And on JOSM, you can "select non-branching way sequence". Kovposch (talk) 08:31, 24 September 2022 (UTC)
Temporarily disused stops
Should temporarily disused stops be kept in the relation (but tagged as disused)? (They're waiting for the aquarium to be rebuilt. They left the bus shelter there but buses temporarily do not stop there anymore.) Jidanni (talk) 13:45, 24 September 2022 (UTC)
Not a stop either way
- Some platforms / bus stops have entry only/exit only restrictions. For those cases, use the roles "platform_exit_only" and "platform_entry_only" instead of the role "platform".
Or the bus is making a left turn so can't stop at the stop. Leaving it off the relation would cause the map to be very much distorted, for software that only incorporates stops, and not streets. Jidanni (talk) 05:44, 6 October 2022 (UTC)
Or, many nearby relations are missing a lot of stops... not fully mapped yet. So one would think that maybe this stop has been forgotten for this route too. But we want to show that indeed this stop has not been forgotten, so no need for passengers to call the bus company and ask, it's just we want to make clear that the stop is not going to be stopped at for various reasons. For instance an express bus that skips every other stop. Jidanni (talk) 05:48, 6 October 2022 (UTC)
Can't add stops to relations that aren't nearby
- Make an extra "temporary" stop near a current stop.
- Also add that temporary stop to the relation.
- Now move, not copy, that temporary stop the many miles to near where you want to make a stop.
- Voila, you can now make the new stop and add it to the relation!
- Now delete the temporary stop, or move it again near another place that needs help adding to the relation...