Cycling highways are a ‘thing’ in Belgium and The Netherlands, or rather, they will be.

Some stretches already exist, others are still in the planning phase.

The intent is to have them as bidirectional ways for cyclists, ideally 4m wide, without car traffic. Often alongside railroads or canals, sometimes instead of disused railways. Where they cross motorways bridges are planned.

Usually they are also open to pedestrians, horseback riders, skeelers, etc. Some were not open to speed_pedelecs, but that is getting resolved.

In practice there will be certain parts that will always be ‘shared’ with car traffic though and where they cross busy national roads the cyclists won’t have priority for obvious reasons. Building bridges and tunnels everywhere is not possible either.

So more than half of them are still in the planning stage. On OpenStreetMap I like the ability to show where they are planned.

I also like to show what the alternative is that can be used today. Obviously we want to avoid unpaved, cobble_stone/sett and even cycle ways along busy car highways. But often that is simply not possible. Things will improve, but it’s going to take time.

I made the mistake of trying to map each cycle highway from beginning to end with a single route relation. It became apparent that that simply does not work.

I also like the route relations to be a continues stream of ways.

So, I came up with the idea of using superroute relations, after asking the JOSM developers to enable showing continuity across ‘sub-routerelations’. They implemented it for superroute relations. (Big thank you!)

It’s a lot of work, but now we are able to show which parts are already usable, which parts are proposed and how to ride today to bypass the stretches that aren’t realised yet.

I will use F78 as an example. It follows Zuid-Willemsvaart for 55 km from somewhere north of Maastricht to Pelt (formerly Neerpelt/Overpelt). For 32 km it’s a rather dull ride along the canal. Near Tongerlo/Bree things get more complex. Currenty there is a steep staircase of 15m after riders pass a smelly water treatment facility.

https://www.mapillary.com/app/?lat=51.1412672&lng=5.6225556&z=17&pKey=ltBvM23gbmj-5uYgPzXYFw&focus=photo

(The whole ride is on Mapillary. My task was to follow the planned trajectory as closely as possible, so what I propose through Tongerlo is currently missing on Mapillary. It’s not easy to get there - no train stations in that heck of the woods - so it might take a while before I get a chance to go back)

The plan is to create a more bicycle friendly connection at that point, but it’s simply not there yet. So I propose to ride through the center of Tongerlo as an alternative that can be used today. (It might even be a better alternative long term, but that’s another discussion)

First stretch: https://www.openstreetmap.org/relation/11479950#map=12/51.1289/5.6518&layers=C

Planned trajectory: https://www.openstreetmap.org/relation/11479949/history#map=13/51.1403/5.6390&layers=C

Tagged with state=proposed on the route relation, which makes it display dashed on the cycle map and route planners won’t use it.

Alternative: https://www.openstreetmap.org/relation/11479948/history

The last stretch: https://www.openstreetmap.org/relation/11479947#map=12/51.1914/5.5536

Most cycling highways are not as monotonous as this one. Often it’s a combination of dedicated infrastructure combined with mixed traffic. The plan is for those to become cycle_streets, where cars are not allowed to bypass cyclists and where the maximum speed is 30km/h. Of course speed pedelecs can’t ride 45km/h there either.

So I’m using 2 superroute relations and 4 route relations to describe what is already realised, what is planned and what is the alternative. For most other cycling highways it means a lot more route relations. Flexibility comes at a price.

One could argue that the unrealised stretches shouldn’t be on OpenStreetMap yet. I beg to differ. I think they are interesting enough to map. They will be realised, either soon, or no so soon. Work in progress.

If anyone is interested in how I’m converting the single route relations to 2 superroute relations and many a route relation, I’m always willing to do a Google Hangout or Skype conversation about it. Polyglot

First of all, I would like to thank the organisers of the State of the Map to invite me as a scholar and HOT to extend this invitation to the HOT summit.

It’s an incredible experience. I met many new people, but also people I had been communicating with online and that I now meet in real life. It’s a great networking opportunity.

I gave a talk about PT_Assistant, which was received really well. So the next day I did a more interactive session working on a single bus route in Abidjan, Côte d’Ivoire, which we converted to PT v2, or at least the way I like to interpret it, keeping it as simple as possible, while still expressing all that’s needed for it to be useful.

https://www.openstreetmap.org/relation/8771035 https://www.openstreetmap.org/relation/10063024 https://www.openstreetmap.org/relation/8771035

(Work in progress)

During the summer of 2019 Ashish Singh worked on further improvements to PT_Assistant. He improved the data model, which led to a better functioning of sorting stops in public transport routes. It could also lead to nicer visualisations of the routes, but that has not been implemented yet.

In this diary entry I want to highlight some of the new features and explain others that existed before.

Public transport

Validator

In the validator everything related to public transport is prepended with PT:

• It can detect that routes can be fixed by simply resorting the ways

• Or that stops aren’t served.

• It also reports when the highway is not suitable for the mode of transport

• Or that the vehicle goes against oneway traffic, or takes a turn where there is a turn restriction

Visualisation

The route that is currently selected or for which the relation editor has focus (it’s on top) is highlighted in purple with the stops in yellow. The stops have the ref of the route, followed by a sequence number.

Relation Editor

Routing Helper

• The routing helper was added last year and is now better on (wrongly) split roundabouts

• There is also a new option, which makes it possible to split the way that is painted in white. The way that was added last in most cases. If a user does this by selection option 8, they get the possibility to make a turn before the white way’s end node is reached. The user selects option 1, 2 or 3. Often there is only 1, or goes further back by using option 8. Once a turn is selected, it is the white way that is split and the side road becomes the new white way.

Demo

Stops sorter

• Sorting stops was added 2 or 3 years ago, but it sometimes failed when a route passed the same way twice. The stops along these ways were added multiple times, which was confusing and hard to fix manually. Now that the underlying data model was improved, it became possible to add them in a more intelligent way. The model is aware of the side of the road the stop is on and the sorter is aware of the side of the road vehicles drive on in the part of the world where the mapper is editing.

Bicycle routes

Validator

Warnings are prepended with: Bicycle:

Visualisation

• The visualisation of the routes takes into account ways on forked branches that have forward/backward roles.

Relation Editor

Routing Helper

• The routing helper functionality now also works on bicycle routes and is capable of adding forked branches with proper forward/backward roles.

I went to the OSCAL conference about Open Source software and OpenStreetMap in Tirana. It took me 3 years to finally decide to go ahead and do it and I had no idea what to expect when I arrived. But once I was there, I very quickly noticed that everything is perfectly fine and safe in the streets of Tirana. When I arrived at the conference I received a very warm welcome from the organisers who form a very active community in their local hackerspace. I was very happy that I could share some of my experience with OSM, OsmAND and Mapillary, and of course the PT_Assistant plugin. While walking between AirBNB and the venue, I tried to make as many pictures for Mapillary as I could, even on the bus to the airport: https://www.mapillary.com/map/im/k7CBwtE2S8quA5LUvfq19Q (They seem to need cycle highways there too, this guy is risking his life on the motorway)

I tried to get JOSM going on the computers in the classrooms, but that wasn’t a great success, as Java wasn’t installed on the Windows and the virtual machines with Ubuntu didn’t have enough memory to work very well. My plan now is to show the possibilities of JOSM and QGIS during Hangout sessions, maybe Hangout on Air. I never tried that before, but it should work quite well and it’s a great way to overcome the physical distance between us in the period between conferences :-)

I started by installing the QuickOSM plugin.

I clicked on the green looking glass in the new toolbar that appeared.

Query

Key: highway In Brussels

Run Query

It downloaded every highway in the zip code 1000 Brussels.

Now I want to show labels for the street names.

On the middle layer (the one with a horizontal line), I press right mouse button, then Styles / Add,

named it Streetnames.

Right Mouse Button on the layer, then Properties.

Labels

Single labels

Label with: abc name.

Size 7.0000

Color: Blue

On the nodes layer, remove all those red dots by going to Symbology and making them smaller.

Project Create Print Layout

Layout/Layout Properties

Add a new map to the layout.

Under Item Properties, it’s possible to set the scale.

I need a larger sheet of paper, if I want those street names to be readable.

Not sure where to set the paper size. All in all not very complicated, but I guess reading the manual wouldn’ t hurt.

On Saturday the 2nd of February 2019 I went to this event thanks to a grant from Wikimedia Belgium to get me here with 3 fast trains and a somewhat slower one. That last one had to go uphill ALL the time tough, so it had a good excuse :-)

I demoed the PT_Assistant plugin, obviously and had the opportunity to network with several OpenStreetMap contributors who are interested in mapping public transport stops, itineraries and lines like I am.

In the beginning we got an interesting talk about “sustainable transport”, i.e. our generation fulfilling our transport needs without preventing the next generation(s) from doing so as well.

ToniE demoed his Perl script which performs validation on a selection of German PT networks and publishes them as web reports.

We also got a nice presentation of OpenTripPlanner. I hadn’t realised previously how useful it is for multimodal travel.

We may not have mapped a great amount on this day, but discussing how to go about it and exchanging experiences and views on the topic is obviously a very valuable exercise.

The hackerspace in Ulm has marvellous infrastructure, it has to be said. Great idea to have this kind of event there.

In October I went the Hack Weekend in Karlsruhe. It was great to meet with several of the developers of our beloved JOSM editor.

I was also able to demo the new features of PT_Assistant to people with a similar interest in the mapping of public transport.

I think the turn-by-turn based composing of itineraries is a big step forward. If the routing helper can find valid itineraries in other route relations, it will propose those as well. The user can then select 1,2,..,5. It is also possible to backtrack using 9, or to skip using 7.

Now I started working on validating the names, from and to tags in the route’s names. And proposing to add a route for the opposite direction of travel when converting to PT v2.

If no route_master exists yet, the plugin will propose to create one.

This summer Biswesh Mohapatra continued the work started by Darya Golovko and continued by Giacomo Servadei. The first year the main focus was on creating validator rules, that needed more advanced processing than what was possible using MapCSS. A layer for visualising the stops and itineraries of the currently selected route relation, was also a big step forward to get visual feedback about what happened when editing itineraries.

The second year Giacomo added the roundabout splitter, which takes care of all the route relations crossing it, so only those ways that are traversed remain. He also added a map mode that adds a node to terminate the itineraries, splits the ways automatically and only keeps the relevant part in all the route relations affected. Depending on the settings, this node also gets the tag public_transport=stop_position and tags for the mode of transport. Giacomo also added the ability to sort the stops in the route relations based on the order of the ways. He also added functionality to visualise bicycle and foot route relations. Especially for bicycle route relations, this helps a lot to get the ways in the right order and with the correct roles, where the path forks.

Biswesh started this summer by adding a map mode for ‘double splitting’ ways, which comes in handy, when you want to add bridges, tunnels, bus bays or traffic calming tables. This even works on 2 ways sharing a common node. You should try it! That functionality alone is worth installing the PT_Assistant plugin.

Then he added a wizard to help you set up the JOSM environment to make mapping of public transport more convenient. I’m afraid we got distracted by other things before it was completely finished though. Noémie asked me where those ‘specialised’ overpass queries went to. We’ll have to look into that. They will probably end up in the history pane of the download window.

He improved the roundabout splitter, which had some quirks and he added support for bicycle route relations to it. We all know those are a challenge to get right.

For the cherry on the pie, some changes were needed in JOSM core. We needed the ability to add some extra buttons to the relation editor. Thank you Michael Zangl for making the necessary changes in core to make this possible!

One of those buttons now enables you to sort stops from within the relation editor, instead of on the selected route relations.

You can find links to screencast videos on the documentation page on the wiki

The button that may completely change how we map bus lines, is what many of you will appreciate the most. We started calling it the ‘Routing Helper’, for lack of a better name. You could also call it ‘Add ways up to next intersection and then ask user where to turn to’. It will however, also look at other route relations and if it finds one with the same 2 ways in it, one were it is at that point in the itinerary and the next one in the route relation, it will present this as option 0. This will usually present suggestions covering a longer distance. It won’t suggest sequences that are not continuous, that travel against oneway traffic, or that don’t heed turn restrictions correctly.

Since our route relations tend to be extremely repetitious, this will mean that if a route between 2 stops is mapped once, it will then be proposed for ‘reuse’ in other route relations.

This will be a big step forward and away from:

• select ways
• select a node
• split
• deselect one part
• add to relation editor
• sort
• rinse
• repeat.

Pressing those numbers may become a bit tedious at times, but it’s at least 10 times more efficient than the list of actions above.

En 2014 Odette Mendy a réalisé un travail de diplôme BTS Géomatique concernant le transport en commun à Dakar. A l’époque elle a utilisé ODK-collect pour répérer les arrêts et ARCGIS pour cartographier les lignes.

Par la suite elle a voulu partager ce travail avec le grand public. OpenStreetMap était le choix logique. Elle a trouvé la communauté OpenStreetMap Sénégal très accueillante et ils se sont organisé pour entâmer ce travail de grande envergure. L’été de 2018 le réseau du département de Dakar est maintenant complètement cartographié. La communauté souhaite élargir ce projet pour les autres localités de Dakar et pour l’ensemble du pays.

Ceux qui ont participé :

Odette MENDY avec l’aide de Ibrahim SANA et Inocent DIBLONI de la communauté OSM Burkina et les membre de la communauté OSM-Sénégal

Lamine NDIAYE Jean Marie MANCABOU Amadou NDONG Ismaïla SEYE Rokhaya SECK Alassane CISS Bougouma Lamine NDAO

It’s no secret that I’m trying to figure out how to simplify mapping of public transport to bring it within reach of all mappers. All without losing the ability to map stops, lines and itineraries in full detail without any limitations. My vision is that a stop with no discernible objects in the middle of nowhere and a stop with all possible equipment should be mapped exactly the same: as a NODE next to the highway/railway.

There are many stop_position nodes I added over time that don’t serve much of a purpose, but then there are some that PT_Assistant’s validator actually started to depend on. It’s those that ‘terminate’ itinerary variations.

Maybe we should get terminology defined first.

What I call a line, is represented as route_master relations in OSM (and confusingly found in routes.txt in GTFS). What I call an itinerary or itinerary variation is represented as route relations in OSM. And stops, well I’d say highway=bus_stop, railway=tram_stop, railway=halt to begin with and public_transport=platform + mode of transport, if you like.

Anyway, stop_position nodes as indication of where an itinerary starts/ends (and splitting the way on those nodes) does make sense.

I still wouldn’t add them for each and every stop though, I still wouldn’t add any details like name on them and I definitely wouldn’t add them to the route relations though. That’s what the nodes next to the highway/railway are used for.

In 2012, the ‘new’ public_transport scheme was voted. What seemed like a good idea at first, has not led to unification though. I was not smart enough at the time to see how this would develop, but today with the benefit of 20/20 hindsight it it’s apparent that we are on the wrong track.

The way the wiki formulates it at present, even though I have tried over the years to keep it in check, we should supposedly map 2 objects for each and every stop and then add both of these to the route relations.

I’m sorry, but that is unacceptable! For one thing, I need a SINGLE object, preferably a node where all the details of the stop go. That has always been the way we do things in OpenStreetMap. The node that gets the stop_position tag is NOT suitable for that purpose, as it is not immediately apparent on what side of the street the stop is.

So, over the years I have tried to work with public_transport=platform and stop_position tags on the stop nodes I’ve been mapping. The idea was that, in time, highway=bus_stop would be replaced by those tags. Only that is not possible, for one thing, those nodes we’re mapping to represent the stops, were not supposed to have a mode of transport on them. So it is utterly impossible to drop highway=bus_stop from those nodes.

OK, let’s step back for a moment: highway=bus_stop is here to stay, wait for it… it’s coming… the conclusion: public_transport=platform tags are NOT ADDING any information. highway=bus_stop says it all. Sorry that it took me a few years to figure that out!

Of course, now the epiphany dawned on me, I decided to revisit all 70000 bus stops around Belgium. So since yesterday I started to remove public_transport=platform/bus=yes tags from all those stops, in packages of about 100-150. Obviously that’s not all I’m doing, some stops have moved, we have better imagery now than we did 5 years ago, there is a new bus_bay tag since last summer. It will take 6 to 12 months to complete this mission, but soon those tags that don’t add actual information will disappear from sight.

It’s time we came up with a scheme to map public transport that is: * easy to work with * easy to maintain * easy to visualise and that: * does not duplicate information * does not force mappers to add 2 objects to route relations

I have a clear vision of how we can accomplish that.

It seemed like a good idea on the face of it. Stops on the highway became public_transport=stop_position, stops next to it public_transport=platform.

But then it was suddenly necessary to add both these objects to the route relations. Already the fact that more than one object became necessary to describe a single bus stop, should have raised alarm bells.

There are, of course, some positive things to say about to say about the new scheme. A route_master relation for a whole line. route relations to describe the various itineraries and stops.

But the stops, that’s where it goes seriously wrong. Why on earth is it necessary to add 2 objects to those route relations? As they describe all the variations, there are a lot of them. Lots of work to maintain them. And they break easily.

After the scheme was voted, I was trying my best to map stops according to it. I had my highway=bus_stop nodes which were all nicely positioned next to the highways, so it’s clear on which side of the road they are located.

So I asked on the mailing list: hey what public_transport to use for them? The answer was public_transport=platform. So far, so good.

Since I had 40000 stops to add for half of a small country, I was not going to bother with adding stop_position nodes as well. So I trudged along for a few years.

In the mean time in Germany and France they had a different idea, let’s convert those nodes next to the highway to platform ways (regardless of whether there was an actual platform present in some cases), oh and those stop_position nodes, let’s duplicate all the details for the stops.

So, for the sake of simplicity, I would like us all to come back to our senses. Map each bus stop, exactly once on a node next to the highways and only add these nodes to the route relations. That’s how I will continue to do it in Belgium, although unfortunately in Brussels somebody already started adding stop_position nodes everywhere and adding them to the route relations. Oh well.

So I’m not sure if it will ever happen that we all move to a more sensible scheme, but in case it doesn’t, I promise to continue moaning and bitching about this overly complex way of mapping public transport.

Polyglot

I finally managed to install QGIS 3 on my favourite linux distro. The magic incantation was found here:

sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-key 073D307A618E5811

echo “deb http://qgis.org/ubuntugis xenial main” > /etc/apt/sources.list.d/qgis.list

echo “deb-src http://qgis.org/ubuntugis xenial main” » /etc/apt/sources.list.d/qgis.list

echo “deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main” > /etc/apt/sources.list.d/ubuntugis-unstable.list

echo “deb-src http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main” » /etc/apt/sources.list.d/ubuntugis-unstable.list

sudo apt-get update

sudo apt-get install qgis python-qgis qgis-plugin-grass

for some plugins QtWebKit is needed:

sudo apt-get install libqtwebkit-dev python3-pip python3-setuptools

pip install jupyter==1.0.0 qtconsole

---

To be able to develop Python scripts I did the following:

apt autoremove echo “deb http://qgis.org/ubuntugis xenial main” > /etc/apt/sources.list.d/qgis.list echo “deb-src http://qgis.org/ubuntugis xenial main” » /etc/apt/sources.list.d/qgis.list echo “deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main” > /etc/apt/sources.list.d/ubuntugis-unstable.list echo “deb-src http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main” » /etc/apt/sources.list.d/ubuntugis-unstable.list sudo apt-get update sudo apt-get install aptitude aptitude install qgis python-qgis javascript-common liblwgeom-dev python3-tk apt-get install Qt5-Support apt-get install qt5-designer sudo apt-get install qttools5-dev-tools sudo apt-get install python3-pyqt5.qtsql sudo apt-get install postgresql-client libpq-dev pgadmin3 sudo apt install libqt5sql5-psql sudo apt install pyqt5-dev-tools

There is some talk about a new scheme for mapping public transport on the German forum.

I’ll try to list some requirements such a scheme should have:

STOPS

• It should be easier to map than the mess v2 has become.
• Simple for simple cases
• Scalable to more complex cases, without the need to convert nodes to ways or relations.
• Details like ref, route_ref, operator, network, zone should only appear on a single object.
• By looking at this object it is immediately clear on which side of the road the stop is located.

ROUTES

• The object that represents a stop for a single direction of travel only appears once in the route relations.
• easy to understand, for anybody who bothers to look inside the relation
• straightforward to process for map rendering
• This means that a scheme with ‘hints’ about the routes, using reference points along the way, is not suitable.
• one route relation per variation of the itinerary

It doesn’t really matter that highway=bus_stop, railway=*, highway/railway=platform are used in combination with public_transport tags. Rendering doesn’t seem to be able to go without the ‘deprecated’ tags. Mapping (using JOSM) is more convenient when using public_transport style tags (roles are set automatically for example).

From the above requirements the only logical solution is to use a node to represent the bus stops. highway=bus_stop / railway=tram_stop bus=yes / tram=yes public_transport=platform

If an actual platform is present where passengers can wait, it can be mapped as a way/area using highway=platform and/or railway=platform. No need for public_transport=platform on these areas, lest someone might say we’re mapping platforms twice. And no need for adding these objects to the route relations. They can be added to stop_area relations. My personal preference would be one such stop_area relation per direction of travel, or per platform in bus stations.

I’m preparing a proposal here: https://wiki.openstreetmap.org/wiki/User:Polyglot/Bus_stops_and_routes

This tweet inspired me to write a new diary entry.

BHousel does not like the criticism he’s been getting for several years now.

Drawing rectangular buildings using the iD editor is a lot harder than it ought to be.

My opinion is that if you create a tool that is going to be used by thousands of mappers, you owe it to your users to make sure that they can produce quality work with ease. Especially if the effort to do so would outweigh by an enormous ratio the frustration shoddy work creates for HOT’s validators (and (re)mappers using that other mapping tool), who need to put more time into fixing the mess, than they would have actually mapping those buildings themselves in the first place. It’s not like the science of creating a rectangle based on adding 3 points using 3 clicks still needs to be invented.

This is an ongoing problem for many years. So either it gets fixed one day, or frustrated messages will happen to escape, every once in a while. Or they will get muffled and HOT validators will continue to silently give up on trying to fix the deluge of poorly mapped buildings. Or you can simply unsubscribe from HOT’s Twitter feed. Whatever works for you.

A more constructive solution would be to invite other programmers into the project. I can’t imagine there wouldn’t be candidates.

Here’s hoping that something good can come out of this.

Polyglot

I’m looking at the diary entries once a day now. All too often there is spam content. What can we do about this? Maybe a vote button and if 3 people mark an entry as spam, it is removed from view and verified by an admin?

Jo

Giacomo Servadei continued to work on the PT_Assistant plugin for JOSM

Hiking, bicycle and equestrian routes

The plugin is not just about public transport anymore, it can also highlight hiking and bicycle routes and report problems with their continuity. It now also visualizes forward/backward roles, which makes editing them a lot more convenient.

One of the problems I noticed over the past year, was that while fixing public transport route relations, sometimes foot and bicycle routes were broken and the validator didn’t warn about this. The other problem is that when bicycle routes fork, forward and backward roles are needed, but they depend on the direction of the way and those little arrows are very hard to see.

Now one leg is coloured in blue, the other in red, which makes it immediately obvious whether the route is mapped correctly and it’s easier to know if forward needs to become backward or vice versa.

Public transport improvements

## Tools

• The plugin can now sort stops according to the sequence of the ways in the route relations.

• It can help with splitting roundabouts, while keeping the route relations that pass over them correct

• There is a new map mode to add stop_position nodes. If such nodes are added to the first or last ways of the itinerary, the way is split and only the pertinent part is kept.

• And there is a new map mode to help with ways selection. It will select all ways in between 2 forks, which are suitable for the mode of transport worked on. At the moment this defaults to bus.

Validation

There are also some new categories of problems the plugin reports and proposes fixes for.

• gaps of a single (suitable) way + automatic fix

• a bug with the detection of relations that could be fixed by simply sorting the ways was fixed.

• a new category will tell the mapper about relations that end up with less gaps when the ways are sorted. This can help detect routes tagged with public_transport:version=2, which aren’t composed of a simple sorted sequence of ways for each variation, but instead still have ways for both/all directions of travel in them.

• There is a new category for routes that don’t start or end neatly on a stop_position node near to a corresponding platform node.

• The names of the first and last stops are compared to from and to tags in the route relations.

• A warning is given if the first or last way don’t correspond to the first or last stop in the route relation.

Bogdans Afonins made several improvements to JOSM’s search and to the download dialog:

Search dialog

Search is incredibly powerful in JOSM. It’s possible to add buttons to the toolbar for searches you need over and over again. Some examples:

Select all ways of a roundabout or a closed oneway way, which is in view plus all the nodes of that roundabout that have more than 1 one way connecting to it:

R inview ((junction=roundabout OR closed  oneway=yes) OR ways:2- child (junction=roundabout OR closed oneway=yes))

I use this to make them round and distribute the nodes or to conveniently select all the ways of a roundabout after it was split.

Find all routes that are already public_transport:version=2, which have members in view and which were modified:

R "public_transport:version"=2 route=bus inview modified

Download dialog

The wizard works like in Overpass Turbo, but of course the output will be set to meta, so JOSM can digest it.

Some examples:

[out:xml][timeout:325][bbox:{{bbox}}];
(
  (
    node["highway"="bus_stop"];
    node["public_transport"="platform"]["train"!="yes"]["ferry"!="yes"];
    node["public_transport"="stop_position"]["train"!="yes"]["ferry"!="yes"];
  );
  ._;<;
  way["highway"="platform"];
  way["amenity"="shelter"];
  node["amenity"="shelter"];
  relation["route"="bus"];
);
(._;>;);
out meta;

This will download a skeleton of all bus routes in a the selected region. It’s a bit complicated, but sometimes it’s easier to go from complex to simple, by removing what is not needed for your use case.

Another one (now that I’m on a roll):

[out:xml][timeout:325][bbox:{{bbox}}];
    node["highway"="bus_stop"]["public_transport"!="platform"]->.allbusstopnodes;
    way["highway"];>;._->.allhighwaynodes;
    (.allbusstopnodes - .allhighwaynodes;);
out meta;

This stores all highway=bus_stop nodes in the selected bbox, which don’t have public_transport tags yet in a named container. Then it puts all highway nodes in another. Then it subtracts these, resulting in all highway=bus_stop nodes, which are not part of highway ways.

Over the past few years, I’ve been mapping a lot of bus stops and routes. Over the past few months I’ve been looking around how it’s done in other places around the world.

What I find (this may of course be influenced by what I wanted to find) is that most bus stops start out as a node next to the way, tagged highway=bus_stop, usually with a name on it.

Then somebody comes along, who glues it to the way. Then somebody else comes along who maps a platform next to the way, using a way, copying all the tags over. They do this regardless of the whether a platform actually exists. They think they need this to add 2 objects per stop to the route relations. Somehow the wiki convinces them of the need for this.

Mapping platforms as ways where there aren’t actual platforms feels wrong to me. Adding a set of details to more than one object also doesn’t feel like the most sensible thing to do. Adding 2 objects to each route relation for 1 real life object makes working with these route relations harder to do.

I’d like to see that a casual mapper can start out mapping a bus stop as a node next to the way, as highway=bus_stop.

Possibly they add public_transport=platform to this node. It seems odd to do so, even if no platform is there, but that’s how things evolved. Tagging it as public_transport=platform means that a role platform will be assigned to it in the route relation. (if the route relation has public_transpot:version=2). It’s the answer I got when I asked the question a few years back on the mailing list. I usually put that node more or less where the pole is. But the exact position is not all that important, as long as it’s more or less where passengers will be waiting.

As far as I’m concerned this node is what represents the bus stop at this side of the street, so it seems obvious that this is the node that should be added to the route relations. The nice thing about doing it that way, is that there is no need to transfer details or relation membership from one object to another. This node is there for the lifetime of the stop. One object to work with, containing all the details, including directly available coordinates.

Now the stop_position nodes. First off, I don’t see a need to map all of them and since where I map bus lines they are not all present, I don’t see why we would add any of them to the route relations. No need to repeat the stop’s details on them either.

Then the platform ways. If there are actual platforms, I would tag them highway=platform/public_transport=platform. Nothing more, nothing less. No need to add them to the route relations.

Then the stop_area relations. This is where we get the chance to indicate which platform node(s) belongs to which stop_position node(s) (if mapped) and which platform way (if present). Doing it this way means to have such relations for each group, where a group is the ones on one side of the road or the ones belonging to 1 platform in a bus station. They can then be grouped in a hierarchy of stop_area_group relations, although this is only needed for the more complex ones and for bus stations.

Sometimes I wonder if I should create a proposal for this. Usually I give up before even getting started, as I know how hard it is to convince anyone in the OpenStreetMap universe, once they are set in their ways. Little by little I’m starting to build the courage to go ahead with it after all. Writing these diary entries is a small first step, also to see if there would be support for such a simpler way of mapping public transport.

Also don’t get me wrong, it’s still possible to fill in all the detail of the accomodation surrounding the bus stops, but in a way that builds further on what was mapped previously, instead of converting from one object type to another or needing to add details more than once.

When we started mapping public transport stops, some people insisted on mapping them on nodes next to the way, others thought the right way to do it, was to add them as nodes being part of the highway, thereby losing the information on which side of the road the bus stop was.

Then somebody came by with the idea to unite both ways of mapping. In itself that sounds great. But where do we add the details then? On both? That doesn’t really make sense. It’s a maintenance nightmare.

So we still have some people adding the stops as stop_position nodes on the highways and others mapping them as isolated nodes next the ways as public_transport=platform. But of course a node is not a platform, so others map those as ways and areas. Nothing wrong with that, but why do we need to add all the details to these ways?

For some reason it was decided that both these stop_postion nodes and the platform ways/nodes need to be added over and over again to the route relations. These route relations represent each and every variation of the public transport lines, so there are thousands of them. Another maintenance nightmare.

Why can’t we have a node next to the way, with all the relevant details and add those nodes to the route relations, then followed by a continuous string of ways? The node gets tagged public_transport=platform/highway=bus_stop.

The node isn’t always representing an actual platform. If there is a platform, nothing wrong with representing it as a way or an area. But there is no real need to duplicate all the details like name/ref/route_ref/zone to these ways. And there isn’t really a need to add them to the route relations.

For the simplest bus stops a node next to the way public_transport=platform/highway=bus_stop is all that is needed. It contains all the relevant information and it has coordinates, which makes it convenient to compare it to data from operators.

For more completely mapped bus stops, benches and waste_baskets can be added.

If you want to make explcit where the vehicle stops, a public_transport=stop_position can be added on the highway. For the first and last stops, the way should be split there, as it’s the beginning or end of the route.

But these stop_position nodes are not all that important, so no real need to map them for every stop. Also no reason why the stop details should be repeated on them and no real need to add them to the route relations. It’s enough to add them to stop_area relations.