- 1 Talk section moved here was 'Public Transport'
- 2 Service routes
- 3 Tram tracks
- 4 Copied from main page
- 5 Transit data standards
- 6 Wheelchair and accessibility
- 7 Outdoor elevator with public transport?
- 8 Bike racks
- 9 Doubled tags in master and route relations
- 10 Bus platform: compatibility with PTv1
- 11 Wikidata and Wikipedia tags
- 12 Stop Numbers
- 13 "name" tag vs. "description" tag
- 14 Temporary closure of a bus route
- 15 Routes without line numbers
- 16 Original tags are still more common
Talk section moved here was 'Public Transport'
Why are the approved features from Proposed_features/Public_Transport not copied to this page? Should the features be used now, or are there still problems? The vote ended more than 2 months ago already. Math1985 18:55, 24 June 2011 (BST)
- Yes, the new features should be used. I (and others) did not find time to update the Public Transport page yet. A simple copy is IMHO not good enough. --Teddych 06:48, 25 June 2011 (BST)
- Teddy, please find time for that work, becasue it would be important to see this proposal going officially live. (Even if it is, already.) It's difficult to find what's here and what's on the propsal and so on. Thank you. - Kempelen 22:33, 25 July 2011 (BST)
How to map routes?
I can think of three methods to map bus routes: 1. Copy the routes from a map, for example on the bus companies' website. 2. Go outside and look in all bus stops which buses are announced to stop there. 3. Take a ride in all bus lines.
As far as I know, we have two reasons to not copy data from other maps: copyright/database right reasons and accuracy.
IMO, an overview of bus lines is not a creative work and is thus not protected by copyright (although the rendering of the map might be copyrighted - but we copy the data, not the rendering). For database rights, there needs to be "a substantial investment in obtaining, verifying or presenting the contents of the database". A bus company doesn't invest in obtaining or verifying timetable data, whether an investment is done is presenting a database is not clear to me. So database rights might be an issue with 1 (and maybe even with 2?), but this is not entirely clear.
Methods 1 and 2 might be less accurate (especially outside of Western Europe). Perhaps method 2 might be even more inaccurate than method 1.
Which methods would others consider acceptable? Math1985 19:19, 24 June 2011 (BST)
- Or "4." contact the public transport companies for data. Budapest transport company released the full data to the public one month ago, when they went to Google Maps (in GTFS format). This is great, import is in progress. Kempelen 22:31, 25 July 2011 (BST)
Q. 'Line' is also used in some places for this concept. which should we use? PeterIto 07:39, 6 August 2009 (UTC)
- I think we should stick with 'Routes', as this is the name widely established on OSM. However, we clarify this by calling them Service Routes. For the infrastructure itself, I like the idea of also using the type=route tag, but using type=railway instead of type=train. We could call these Infrastructure routes. Frankie Roberto 11:52, 8 August 2009 (UTC)
This page says that streets with tram tracks should be a single way for both road and tracks; OSM Inspector says that they should be separate ways to keep the names separate. Who’s right? --Wynndale 18:29, 8 August 2009 (UTC)
- I am sure OSM Inspector is right! I have never tagged a tram track personally but have updated the description to match my current understanding (which matches a conversation I have had with someone on the subject some time ago). Would be great to have the views of a tram expert.PeterIto 18:15, 9 August 2009 (UTC)
- I was under the impression that having two ways which use the same nodes was a bad idea (as it makes it difficult to select the different ways in editing tools). That said, I've only been using both tags (railway=tram and highway=secondary) where the tram and the cars share the same physical lane. Where they are grade separated, but part of the same road, then the two should have separate ways. Sometimes you can even get a mix of both on the same road - eg there's one near me where one side of the road, the tram has exclusive use, and on the other side of the road, the tram shares its lane with cars. This makes the road as a whole one-way for cars, but two-ways for trams. I've mapped this using two ways (one for each lane), but it looks a bit crap in current renderers... Frankie Roberto 20:12, 9 August 2009 (UTC)
- Firstly, can I suggest that it is a problem for the editors to solve. Fyi, in Potlatch someone finally showed me how to select any way from a stack of ways. click the node, if the way you want is not shown then type '/' which changes the way, then if that isn't the right one click the node again and type '/' again - repeat until the correct way is shown - not elegant but it does work. Secondly, can I suggest that we move this discussion about Tram tracks to the Trams page and just keep a brief link to it from this page? PeterIto 06:28, 10 August 2009 (UTC)
Copied from main page
Think these two need more work/thinking, as well as some examples. Frankie Roberto 22:36, 21 September 2009 (UTC)
A Line Variant can be used to define a particular calling pattern used by some vehicles operating on the Route.
A Line Variant is a relation which details a distinct ordered calling pattern for vehicles using a Route and there will normally be at least one Line Variant for each direction of travel for a Route. Each calling point should either be defined as a Stopping Place or Access; for preferences Accesses should be used, however if the actual Access cannot be determined for a particular calling point then the Stop Place should be included instead (Accesses will not known at calling points where the Access is allocated dynamically shortly before the actual vehicle arrives). Set-down only calling points can be assigned with the role
Set-down only or
Using a Line Variant in association with a Route it should be possible to determine a single unambiguous route through the network. If this cannot be determined due to there being two valid routes between two stop points then one or more suitably chosen additional infrastructure nodes should be included as '[passing points' in the Line Variant within the ordered list at the appropriate position.
The following tags can be used:
A Line Variant should be a member of a Route Relation.
A group of routes can be combined together to form a Network. A single route can, if necessary, be part of more then one network.
||text||name (e.g. Chicago Transit Authority)|
||text||abbreviation of the name (e.g. CTA)|
One or more Routes can be a member of a Network relation.
Transit data standards
Transmodel is the European Reference Data Model for Public Transport. It is an abstract conceptual model to represent common public transport concepts such as network timetabling, ticketing, operations and realtime data. Transmodel is an important design tool, informing and guiding the design of public transport information systems.
If you want to follow the current discussion on the relevance of Transmodel to OSM and how OSM data will achieve compliance, join the mailing list firstname.lastname@example.org.
IFOPT (Identification of Fixed Objects In Public Transport)
IFOPT (Identification of Fixed Objects in Public Transport) is a prCEN Technical Specification that provides a Reference Data Model for describing the main fixed objects required for public access to Public transport, that is to say Transportation hubs such as airports, stations, bus stops, ports, and other destination places and points of interest, as well as their entrances, platforms, concourses, internal spaces, equipment, facilities, accessibility etc.)
Wheelchair and accessibility
Q How explain if the station was being built for wheelchair with the new system ? In the past, we used highway=bus_stop and wheelchair=yes/no/limited. How we can do with the new system? Could we use wheelchair=yes/no/limited with platform ( station seem be to big for wheelchair=yes/no/limited ) ? --APP3L initiation (talk) 20:13, 4 March 2013 (UTC)
Outdoor elevator with public transport?
There is a unapproved proposal on elevators: http://wiki.openstreetmap.org/wiki/Elevator
How should this be used now with public transport?
Making two nodes on bottom and top with public_transport = stop_position elevator=yes
How could I know which is top and which is bottom? And I will have to cheat to get a little stretch of way, since often, elevators are exactly vertical ...
How to map transit service with bicycle carriers on the vehicles? In my city, several bus routes have some (not all) busses equipped with two bike racks for the passengers. Analogous to wheelchair=no/yes/limited, this could be bike_rack=no/yes/limited/partial.
Are there other types of bicycle accommodation on public transit? I guess some services might let passengers roll their bikes into the passenger compartment, or provide bike lockup. Perhaps it should be bike_carrier=rack. But then how to indicate that only some vehicles have this equipment? Should capacity be indicated?
- Use bicycle=yes on the type=route relation -Miklcct (talk) 01:36, 25 April 2017 (UTC)
- Yes but still with route=bus. The route relation indicates a bus line, independantly of the type of highways permitted to and used by buses (still buses cannot go on cycleways if these highways don't have themselves a bicycle=yes). Normally QA analysers will detect routes that use incompatible ways.
- However the question is more precise: bike_carrier=rack is a specific equipment within buses. It may exist buses where user's bikes may be transported, but only with luggages and on specific stations where buses can stop; there could also be an open area within buses where bikes may be parked, but without any attachment (passengers still need to stand near it and cannot sit down, and if the bus is too crowded, they won't be able to enter: priority will be given to wheelchairs or small carriers for young children or smaller luggages).
- The same question may occur for train routes (only in some cars of the train that have a platform: many trains are not easy to climb into with bikes, and the doors must remain accessible for other passengers, I'm not talkiing about the very dangerous overcrowded trains in poor countries where many passengers are traveling on the rooftop or hanging to the windows or to open doors or could send their bike to the roof: there's no real equipment except on some train "cars" that are only open platforms noramlly made for the freight).
- If there's such equipmeent for cycles onboard, additional keys may be needed such as the presence of a lock to secure the bike from falling or from being stolen by other passengers. In many buses, bikes are accepted only where the bus has a long stop and the bus driver will secure it with other luggages: passengers cannot do that themselves. In trains, it is possible to give your bike to a railway personnel that will put it in a specific car for the freight: that car is not open to the public (this is rare on modern high speed trains for long distance travels: you must buy a separate reservation ticket and your bike will be conveyed sepoarately and delivered some hours or days before or after your travel). For short distance city buses with many stops, it's not possible for the driver to handle luggages, there must be a specific equipment open to the public within buses, suitable for bikes or large luggages. — Verdy_p (talk) 02:03, 25 April 2017 (UTC)
Hey, I would like to know why the page states that the tags ref, ref:<qualifier>, operator, network, and color are recommended. The proposal says: "recommended if no route_master=* exists, else optional". There must be a reason why it did not say "recommended". Editing PTv2 relations in north-east Germany, my experience is that every route relation has all of the tags mentioned above. If something changes, however just one or two values are updated by fellow mappers. This is why I see the current situation as a second choice, but surely not as good as it could be and not the way it was meant to be. I would therefore suggest to change the wiki page accordingly. Are there any opposing views? U30303020 (talk) 13:45, 4 January 2018 (UTC)
Bus platform: compatibility with PTv1
Regarding the recent changes of the wiki page, I'm wondering if it's a good idea to add a separate highway=bus_stop if the platform is already mapped with public_transport=platform, because only one of it can be added to the bus route(s). What is wrong with adding highway=bus_stop to a public_transport=platform way or area? This is what Key:public_transport recommends and what iD's Bus Stop / Platform presets do, too. --SelfishSeahorse (talk) 08:24, 10 March 2018 (UTC)
- In PTv1 there was no distinction between stops and platforms, they were the same object (bus_stop nodes), almost always not on the road but beside it; there was no clear platform. And routing them was a problem.
- PTv2 makes the distinction by placing stop_positions on roads (allowing correct routing). But platforms are not recognized by v1 applications, and that's why for compatiblity with these v1 apps only, a "bus_stop" node is still needed on the platform. When the platform is an unclosed way or closed way/area, we need the additional node, only used by v1 apps, not used at all by v2 apps. But I have doubts that v1 "bus_stop" could not be used as well on the platform object, even if it's an unclosed way or closed way/area (possibly a multipolygon relation). But I suppose that most v1 apps remaining are only accepting single nodes, and in this case that bus_stop node should be near on the platform the position where the bus stops and there's a bus_stop sign.
- Note that most platforms for buses are still single nodes, so there's no need to create an extra node for compatibility, only tag the platform node also with highway=bus_stop.
- Still, even if there's highway=bus_stop on that platform node, you need bus=yes (platforms are designed to be possibly multimodal, not just for buses, they could be used for taxis, or trams, with their own stop positions (possibly not the same stop_position if they are not exactly on the same type of way: note that a platform may have two sides, one along a highway for buses, another side along a light railway track for trams or a separate service way for taxis).
- Adding this extra bus_stop node on platform ways/areas may still causes some problems. In my opinion these compatibility nodes should NOT be part of v2 "stop areas" to avoid detection of duplicate stops (e.g. for the tool that attempts to render line sketches). — Verdy_p (talk) 08:52, 10 March 2018 (UTC)
- Note that with the slow development/migration to PTv2, msot apps still depend on PTv1 and many still don't care about PTv2 at all. This is progressing, but variably depending on cities where maps using PTv2 have been now been deployed. Completing Public transport lines is a big task that also needs regular maintenance (at least once each year in most cities, sometimes at each season, notably for buses; metros and rapid systems are more stable, but much simpler in comparison to maintain). — Verdy_p (talk) 12:08, 10 March 2018 (UTC)
- In this case, it seems to make more sense to add only the bus stop node (highway=bus_stop + public_transport=platform + bus=yes) to the route relations, but not the platform (highway=platform). Because otherwise these apps display a bus stop icon but you don't get informations about the routes. --SelfishSeahorse (talk) 12:54, 10 March 2018 (UTC)
- No, because platforms are part of route relations with the role "platform", even if they are ways or areas. The legacy v1 bus_stops are transitory but we should favor the v2 to allow the transition, otherwise we would be frozen to v1. The ways/areas for platforms are already part of v2 route relations.
- But may be if route relations are still in v1 we could have these legacy nodes and not the way/area platforms: converting the v1 route to v2 would require replacing the legacy v1 nodes by v2 ways/area platforms, but not keeping both as members. Note also that stop areas are only in v2, not in v1, and it does not make sense to add these v1 bus_stop nodes to these stop areas.
- This remark applies only when platforms are ways/areas (for a minority of stations), but not when they are (most frequent case) just nodes (having both tags as highway=bus_stop in v1 and public_transport=platform+bus=yes in v2).
- And there's no such highway=platform tag, platforms in v2 are (or should be) only public_transport=platform; if you find them, they should be converted instantly to v2 without ambiguity ! — Verdy_p (talk) 14:18, 10 March 2018 (UTC)
- This is incorrect. The proposal in 2011 listed highway=platform as one of the existing tags and said that none of them would be deprecated by the propoposal. This tag is still needed, because a public_transport=platform does not specify if it is a bus stop with only a sign (or even no sign), or if there is actually and elevated platform. A highway=platform is an elevated structure used for boarding a bus, similar to a railway platform. There is no replacement for this tag. Even for highway=bus_stop the tag public_transport=platform alone is not sufficient, because it doesn't specify if the stop is for a bus, a tram, or a train. --Jeisenbe (talk) 15:39, 29 July 2019 (UTC)
I wonder what is the most appropriate object for those tags: should they go to the route master relation only, or to every itinerary variant route relation, or on both master relation and route relations, at the price of duplication of the same information and potential maintenance problems? Bxl-forever (talk) 22:57, 17 June 2018 (UTC)
Every stop in our bus system has a unique number on its sign. This number can be used to access arrival estimates by phone, text or web. Should this number be recorded (I believe it should) and if so, how? —Preceding unsigned comment added by TreeStryder (talk • contribs) 13:02, 31 August 2018
- Hi! This is a good question. Unfortunately i can't help you. There's ref=*, but together with public_transport=platform it is used to tag the platform number or letter. You might want to ask your question on the Talk-transit mailing list. The mailing lists are the main communication channel on OpenStreetMap. Regards --SelfishSeahorse (talk) 14:40, 9 September 2018 (UTC)
- PS: There's also the undocumented tag stop_id=* (see Taginfo).
"name" tag vs. "description" tag
- @Johnparis - are you claiming that "name tag is supposed to be used for name, not description" is just "one person's opinion"? I am pretty sure that "Name is the name only" is not just my personal preference - see https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only Mateusz Konieczny (talk) 19:21, 11 May 2019 (UTC)
Perhaps I am unclear. It is your opinion that "Bus 93: Chatelet -> Montmartre" is a description. It is, in fact, by consensus, the name, as stated in the proposal. It is in fact also a description of sorts -- all names are descriptions in one way or another -- but to say that it is only a description is your opinion, not a fact. As stated in the page you cite, "It is certainly wrong for a mapper to invent a name for an airstrip; however most names were invented at some point in history, so if someone invents a name and it catches on and a sizeable group of people refer to the thing by that name, then it's ok to be mapped." Johnparis (talk) 14:20, 30 May 2019 (UTC)
Temporary closure of a bus route
A public transport company decided that some certain bus routes wouldn't be active during the summer which brings up the question of how to tag them. I believe it would be inappropriate to delete the routes as they will (most likely) be reactivated in the autumn. Is there a way to mark the routes in such a way that software would know not to display and/or utilise it during a certain defined time period? If not, how could I tag the routes so I could fairly sure the software would ignore it while the tag is there, while still keeping the associated data intact until it's reactivated? -Svavar Kjarrval (talk) 09:46, 12 May 2019 (UTC)
- I would prefix
disused:route=bus. Regards --SelfishSeahorse (talk) 09:53, 14 May 2019 (UTC)
- I would use a lifecycle prefix as proposed by Selfish Seahorse; perhaps disused is the best. In any case it's important not to use a tag that will be harmful if not changed at a certain point, so at the least a checkdate or opening date (as with a construction prefix) would be useful. Johnparis (talk) 14:24, 30 May 2019 (UTC)
Routes without line numbers
In Greece regional buses usually dont't have line numbers, but city buses have. As a result, map shows IDs (line numbers) for the city buses only, while regional buses are represented by a nameless red line. Thus it is impossible to follow the course of the regional bus in the city (example: osm.org, ÖPNV-Karte). I understand that we shall not "invent" references that do not exist in nature, but is there any other solution for this problem? Should the renderers create a "synthetic ID" from from=*/to=* or use name=*? --GerdHH (talk) 11:08, 25 June 2019 (UTC)
- I could imagine making use of the color=*, but you should direct your requests to the companies standing behind these maps, because they are the only ones with the ability to change their rendering.
- In case of the first company, I can assure you that someone reads your message, I have contacted them in different matters before. --Tigerfell (Let's talk) 21:13, 27 June 2019 (UTC)
- It seems reasonable for renderer to make "synthetic ID" from from=*/to=* - but decision, as usual, is completely up to whoever makes it Mateusz Konieczny (talk) 21:14, 28 June 2019 (UTC)
I've check the data with Taginfo and https://taghistory.raifer.tech, and the original "V1" tags are still more common than those using public_transport=*. The most extreme examples are for aerialway=station and amenity=ferry_terminal which are many times more common than the public_transport=* option, but common feature like bus stops are still more commonly added to the database with highway=bus_stop instead of public_transport=platform as of 2018 to 2019. I've made some edits to the page to mention which tags are actually more commonly in use. While some mappers seem to think that tags like railway=station should be discouraged (even though the proposal did not suggest this in 2011), the data shows that most mappers are continuing to add new features with the simpler, more specific tags. --Jeisenbe (talk) 15:51, 29 July 2019 (UTC)