Cycleway:both and one way traffic

(I write this in English, because the problem occurs in both language communities.)

A number of mappers replace the oneway:bicycle=no tag with the tag cycleway:both=no, playing havoc with routers. Is there any rationale for this and, if no, how can we prevent this?

Can you provide a link to one or more changes where this happened?

1 Like

Is it happening on oneway=yes / oneway=-1 roads where cyclists can travel in both directions?

Or is it happening where road is oneway for cyclists?

Is it a single account or many? Has anyone let them know about problem via changeset comments?

Which editor they use?

How many edits are like this? 2? 20? 20 000?

When this edits were made and with which editor version? Maybe editor developers already acted to prevent bad edits? Are any happening with recent editor versions?

An example is I ran a query, and obtained about 700 ways in Belgium with oneway=no and cycleway:both=no, but not oneway:bicycle=no. Of course, some of these may be genuine oneway for bicycle, or oneway:bicycle was never tagged in the first place.

To see whether cycleway:both=no was used as a replacement for oneway:bicycle=no, I have to manually check the history. The first three examples I found of this were by three different mappers, which put me off of the idea of contacting the mapper. As it is, the only way I see to repair the damage is to check all the ways affected whether they should have oneway:bicycle=no, a huge task, without the guarantee that ths problem will not come back.

This was a bug or unclarity in StreetComplete that has been fixed. Someone can write a script to detect the still existing mistakes in the data.

Good catch!

Assuming you meant

I ran the Overpass wizard query (cycleway:both=no and (oneway=yes or oneway=-1) and oneway:bicycle!=*) and type:way in Belgium, which currently gives 742 results. I did 15 spot checks. Most roads did not have oneway:bicycle=no to begin with.

The road you linked and the 1 incorrect modification that I did find, were done with StreetComplete in the “specify whether there are cycleways” quest.

Way Editor
w404960569 StreetComplete 28.0
w180020707 StreetComplete 37.2

There is a discussion on these forums about this topic: When does StreetComplete remove oneway:bicycle=no? - #6 by westnordost
Apparently StreetComplete now has a better interface, to avoid this error from being newly introduced in the data any more.

Luckily there are people who can write a script in an hour to do this :slight_smile:

1 Like

One would wish, of course. I can write such a script (needs more than an hour though: I have to find out how to look at the history of a way first), but I find that there always snags with such scripts: exceptions and special cases giving an unexpected result. Apart from that it is probable that many of the 700-ish ways are error prone anyway and need checking. Work for some long winter evenings, and that just when summer is coming.

But it seems the problem will be international. Maybe it is relevant to warn other communities of the problem.

url = '' + object_type + '/' + object_id + '/history.json'

I filtered the history for all ways matching


This takes data for the whole planet.

The counts are as follows:

In the same changeset ... added cycleway:both=yes added cycleway:both=no added other cycleway:both didn't modify cycleway:both
removed oneway:bicycle=yes 0 12 0 4
removed oneway:bicycle=no 0 875 0 71
removed oneway:bicycle=-1 0 0 0 0
removed other oneway:bicycle 0 0 0 0

Not included in the table above:

there was never a oneway:bicycle 96253
oneway was added after cycleway_both was added 4323
tags were changed after downloading from Overpass,
so the way didn't match the query way any more

The script and data are available at midgard / Vespucci cycleway and oneway data analysis · GitLab.

(The full analysis took 3 hours, a bit more than 1 indeed.)

1 Like

This leaves 887 ways worldwide that had a changeset that dubiously removed oneway:bicycle=yes/no and added cycleway:both=no at the same time.

The nearby ways should also be checked, because a way can have been split after this modification. @JanFi’s call for manual inspection due to probable error-proneness of these ways is also relevant.

I might not be able to follow up on this in the near future, so if someone wants to take this data and do something with it, go for it.

hmmm, Is this another gungho gone global edit, undiscussed/unapproved challenge? We’ve got quite a few oneway streets with mostly painted cycle lanes, sometimes coloured with the bike symbol on it tagged within oneway:bicycle=no, not mapped separately but tagged onto the street, some are painted on the sidewalks which too are tagged onto the street, not mapped separately. Some are signed with such that it translates to oneway:bicycle no then shared with the busway, either oneway:bus=no or oneway:psv=no and in cases oneway:emergency=no.

This is a case where a since-corrected editor bug has caused data corruption (removal of a tag where we assume the mapper wasn’t aware of this). If fixing it would need to adhere to organized editing guidelines, then that can be arranged.

1 Like

I’m always using oneway:bicycle=no when mapping in my area (Seneffe, Manage, Morlanwelz, Chapelle-lez-Herlaimont), 74 références…