Improve AddPathSurface/AddCyclewayPartSurface/AddFootwayPartSurface interplay for segregated cycle ways

[peternewman]

Use case When completing AddPathSurface, I've found some segregated cycle ways which don't have the tags StreetComplete is expecting, it offers me the option to split along it's length, but not it's width.

For example: https://www.openstreetmap.org/way/576119011 highway=cycleway segregated=yes

Proposed Solution I think the fix might be two-part:

• Tighten AddPathSurface to exclude segregated=yes
• Loosen AddCyclewayPartSurface to not require surface=paved (which is surely incorrect if the two sides are different). Also remove the requirement for bicycle ~ designated|yes; if it's segregated it implies both bicycle and pedestrian according to the wiki. Perhaps the solution is to check for bicycle!=no or even !bicycle or bicycle ~ designated|yes?
• Likewise make the equivalent changes in AddFootwayPartSurface

If we should be tagging bicycle/foot designated, it could also add those as part of it's change?

Otherwise reading the code it seems I should AddPathSurface and select the generic paved option, but then I can't see any way to set the bicycle/foot tags on the way.

[peternewman]

It seems @rugk agreed with me: https://github.com/westnordost/StreetComplete/pull/1493#discussion_r309139736

[peternewman]

Re-reading the other comments, the other solution would be an edge case "other" answer on AddPathSurface for this specific usage.

[westnordost]

What would you say @matkoniecz, you made that quest.

[westnordost]

Without having reread the comments there, I think @peternewman 's solution makes sense and expects the data less to be exactly in a very specific format (surface=paved).

[peternewman]

If there is desire to map the base common surface, then reworking the quest to do both sides at once like the cycleway one would allow the most specific common surface to be added to the master one (e.g. if they're both tarmac, or the more generic paved if they're different).

[matkoniecz]

Without having reread the comments there, I think @peternewman 's solution makes sense and expects the data less to be exactly in a very specific format (surface=paved).

I think that it would be also OK. I am unsure how often false positives would appear or even how to check ratio of such invalid quests, but it should be fairly rare.

Personally I prefer to be conservative with quest filters. I prefer showing 100 valid quests over showing 200 valid and 1 invalid.

What would you say @matkoniecz, you made that quest.

I think that it would be OK to make proposed changes, though I am not planning to make PR for them. I assume that current situation is not considered as buggy, in such case I would make a PR.

But I certainly can review PR or help in case of some coding issues.

reworking the quest to do both sides at once like the cycleway one

I though about this at one point, I admit that primary reason for not doing this was that it was a more complicated solution. Possibly with too complex UI.

It is not possible to reuse sides interface, as position of footway vs cycleway is unknown.

I think that it would be nice to test it, but I am not planning to do this.

---

Loosen AddCyclewayPartSurface to not require surface=paved (which is surely incorrect if the two sides are different)

Why? With both sides paved but with different materials what is wrong with surface=paved? IMHO it is the only possible value in cases like https://wiki.openstreetmap.org/wiki/File:Witosa_bike_2.jpg (assuming that cycleway and footway are tagged together on a single line with segregated=yes).

---

Perhaps the solution is to check for bicycle!=no or even !bicycle or bicycle ~ designated|yes?

My original motivation was to ensure that quest in every single case is correct or current tagging tagging is wrong. I am not sure whatever loosening requirements would have real increase of false positives.

Maybe add one more quest asking about bicycle value where it is not tagged?

---

If we should be tagging bicycle/foot designated, it could also add those as part of it's change?

I would not add it blindly, asking possibly invalid question is probably acceptable (assuming that it is happening very rarely), but silently adding tags seems a poor idea.

---

if it's segregated it implies both bicycle and pedestrian according to the wiki

Huh. I never expected such interpretation with limiting it solely to ways with both pedestrian and bicycle traffice.

https://wiki.openstreetmap.org/wiki/Tag:segregated=yes?uselang=en-GB describes segregated=yes as

Used to show that there is some form of segregation between pedestrians and cyclists on a cycle path or footway.

but is it really used solely in such cases? It will be appearing far, far less often but path may be split in parts for say pedestrians and equestrians. Or for golf carts and pedestrians.

Or is it so rare that it is better to ignore it?

[peternewman]

Without having reread the comments there, I think @peternewman 's solution makes sense and expects the data less to be exactly in a very specific format (surface=paved).

I think that it would be also OK. I am unsure how often false positives would appear or even how to check ratio of such invalid quests, but it should be fairly rare.

I'm unclear what false positives there can be, it's a cycleway due to other matching logic, I don't see why a segregated unpaved one couldn't still differ between the bicycle and foot sides?

Personally I prefer to be conservative with quest filters. I prefer showing 100 valid quests over showing 200 valid and 1 invalid.

What would you say @matkoniecz, you made that quest.

I think that it would be OK to make proposed changes, though I am not planning to make PR for them. I assume that current situation is not considered as buggy, in such case I would make a PR.

But I certainly can review PR or help in case of some coding issues.

reworking the quest to do both sides at once like the cycleway one

I though about this at one point, I admit that primary reason for not doing this was that it was a more complicated solution. Possibly with too complex UI.

I understand the re-use bit, aside from pictures rather than icons it's no more complex than the existing cycleway one, which shows ~ 10 different icons for either side of the road.

It is not possible to reuse sides interface, as position of footway vs cycleway is unknown.

Do you mean there's no tag logic to represent it? Wouldn't that potentially be useful info to gather and standardise (in the same way as is done for the other ones like that and pavement, or is that relative to the direction of the way or something?

Loosen AddCyclewayPartSurface to not require surface=paved (which is surely incorrect if the two sides are different)

Why? With both sides paved but with different materials what is wrong with surface=paved? IMHO it is the only possible value in cases like https://wiki.openstreetmap.org/wiki/File:Witosa_bike_2.jpg (assuming that cycleway and footway are tagged together on a single line with segregated=yes).

I can understand the logic (although I'd also argue the other possible value is not to tag it; from a data perspective, what happens if it gets tagged as surface=paved and surface:bicycle=dirt and surface:foot=carpet, then what am I supposed to believe), I'd still argue if that's standardised (which I can't immediately see in the wiki) and if you want to maintain the query then the surface quest needs updating to offer a special other option when you're tagging a segregated way. Or the text prompt needs tweaking, otherwise unless you've read the bit of the wiki I clearly haven't found yet (which I didn't think was the target users for StreetComplete anyway), how are you supposed to know to tag with the most generic common one.

I'm also curious what the appropriate tag to use on this segregated way would be (or should it actually be two parallel ways): https://stock.adobe.com/lv/images/bike-path-with-a-dirt-jogging-trail-in-rancho-cucamonga-california/221906728

Perhaps the solution is to check for bicycle!=no or even !bicycle or bicycle ~ designated|yes?

My original motivation was to ensure that quest in every single case is correct or current tagging tagging is wrong. I am not sure whatever loosening requirements would have real increase of false positives.

Maybe add one more quest asking about bicycle value where it is not tagged?

In the area around London, there are just under 1300 segregated ways with a bicycle value that isn't no: http://overpass-turbo.eu/s/MQU

Yet there are 1600 segregated ways with no value for bicycle, foot or horse: http://overpass-turbo.eu/s/MQV

Interestingly Paris is a lot better with 298 segregated with bicycle, versus 90.

So either we desperately need a quest to find out what's allowed on the segregated way, or we need to drop the requirement and assume everyone is reading the wiki and working on the default. Or accept that the vast majority of segregated ways won't ever have surface added in this area.

If we should be tagging bicycle/foot designated, it could also add those as part of it's change?

I would not add it blindly, asking possibly invalid question is probably acceptable (assuming that it is happening very rarely), but silently adding tags seems a poor idea.

Surely if we've just asked what the surface of the cycleway part is, it's acceptable to say that a bicycle is allowed there? Do you really need another quest asking "is a bicycle allowed here"; I guess if you kept the restriction and had it first you would.

if it's segregated it implies both bicycle and pedestrian according to the wiki

Huh. I never expected such interpretation with limiting it solely to ways with both pedestrian and bicycle traffice.

https://wiki.openstreetmap.org/wiki/Tag:segregated=yes?uselang=en-GB describes segregated=yes as

Used to show that there is some form of segregation between pedestrians and cyclists on a cycle path or footway.

but is it really used solely in such cases? It will be appearing far, far less often but path may be split in parts for say pedestrians and equestrians. Or for golf carts and pedestrians.

Or is it so rare that it is better to ignore it?

If you want to track who's segregated, the tag scheme probably needs extending a lot, I think it would be fair to say pedestrians are always likely to be separated from other things, but if you've got foot, bicycle and horse, is that three bits of track or two split foot/bicycle+horse that probably wants encoding in the tags too?

I'm unclear which access category your golf cart falls into: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

[matkoniecz]

I'm unclear what false positives there can be, it's a cycleway due to other matching logic, I don't see why a segregated unpaved one couldn't still differ between the bicycle and foot sides?

highway=footway segregated=yes without cycleway but asking about cycleway surface.

Do you mean there's no tag logic to represent it?

There is something but it is used extremely rarely. Adding quest is feasible but I am a bit dubious of it usefulness given gathering effort.

, what happens if it gets tagged as surface=paved and surface:bicycle=dirt and surface:foot=carpet

At least in such situation problem is detectable, what is good. Missing surface=paved would not help.

I'm also curious what the appropriate tag to use on this segregated way would be (or should it actually be two parallel ways):

Two ways given physical separation (?)

So either we desperately need a quest to find out what's allowed on the segregated way, or we need to drop the requirement and assume everyone is reading the wiki and working on the default.

I fully agree here. Not sure what is the correct answer.

[peternewman]

I'm unclear what false positives there can be, it's a cycleway due to other matching logic, I don't see why a segregated unpaved one couldn't still differ between the bicycle and foot sides?

highway=footway segregated=yes without cycleway but asking about cycleway surface.

Yeah I'd originally suggested this: !bicycle or bicycle ~ designated|yes

It probably needs refining to something like this (pseudo-code as StreetComplete seems to use different logic to OverpassTurbo: (highway=footway and segregated=yes and bicycle ~ designated|yes) or (highway=footway and segregated=yes and !bicycle and !foot and !horse (and ! any other valid tags))

Do I take it you can't think of false positives with not requesting surface=paved?

Do you mean there's no tag logic to represent it?

There is something but it is used extremely rarely. Adding quest is feasible but I am a bit dubious of it usefulness given gathering effort.

Wouldn't it be less hassle to fill in both sides in one go rather than as two quests as currently happens?

, what happens if it gets tagged as surface=paved and surface:bicycle=dirt and surface:foot=carpet

At least in such situation problem is detectable, what is good. Missing surface=paved would not help.

I'm also curious what the appropriate tag to use on this segregated way would be (or should it actually be two parallel ways):

Two ways given physical separation (?)

Yeah not a perfect photo, I could possibly imagine something similar as one path, where they only tarmacced half of it to save money.

So either we desperately need a quest to find out what's allowed on the segregated way, or we need to drop the requirement and assume everyone is reading the wiki and working on the default.

I fully agree here. Not sure what is the correct answer.

Given the segregated tagging doesn't deal with, or handle three things, e.g. foot/bicycle+horse, should it be excluded from StreetComplete for now to ensure duff data doesn't enter the system?

[westnordost]

@peternewman I did not follow your discussion. Could you summarize what conclusion you two reached, what exactly I should change now?

[peternewman]

I still believe there are three sets of changes:

• Tighten AddPathSurface to exclude segregated=yes
• Loosen AddCyclewayPartSurface to not require surface=paved. Also update the valid ways to match (psuedo-code): (highway=footway and segregated=yes and bicycle ~ designated|yes) or (highway=footway and segregated=yes and !bicycle and !foot and !horse (and ! any other valid tags))
• Likewise make the equivalent changes in AddFootwayPartSurface

Potentially re-engineer as one quest like the cycleways on a road ones, but may be too much effort to be worth it. It could then do some additional tagging with the common knowledge.

I'm unclear how much of that @matkoniecz agrees with.

[westnordost]

Oh, so that means that you did not reach a consensus? Well, I guess that means I won't get around reading the whole thread again, so be it.

[peternewman]

Oh, so that means that you did not reach a consensus? Well, I guess that means I won't get around reading the whole thread again, so be it.

Well @matkoniecz hasn't replied to my most recent comment so I can't do much to reach a consensus unfortunately.

[matkoniecz]

Sorry for not replying! And thanks for a reminder.

I am perfectly fine with what was proposed in https://github.com/westnordost/StreetComplete/issues/1587#issuecomment-544201327 and I would not oppose it.

---

below are probably less useful replies

It is not possible to reuse sides interface, as position of footway vs cycleway is unknown.

Do you mean there's no tag logic to represent it?

There is something but it is used extremely rarely. Adding quest is feasible but I am a bit dubious of it usefulness given gathering effort.

Wouldn't it be less hassle to fill in both sides in one go rather than as two quests as currently happens?

Maybe it is a regional issue but in Poland footway very often changes sides with cycleway. Answering such quest would require splitting way multiple times.

This is well visible in https://www.openstreetmap.org/search?query=Warszawa#map=19/52.23181/20.99330 where someone mapped footway and cycleway separately

What worse, quite often you have cycleway with footway on both sides of it (again, maybe regional issue).

Not sure whatever such "interesting" ideas for cycleway construction are popular also in other areas.

So either we desperately need a quest to find out what's allowed on the segregated way, or we need to drop the requirement and assume everyone is reading the wiki and working on the default.

I fully agree here. Not sure what is the correct answer.

Given the segregated tagging doesn't deal with, or handle three things, e.g. foot/bicycle+horse, should it be excluded from StreetComplete for now to ensure duff data doesn't enter the system?

What and where should be excluded?

[westnordost]

I created a PR now

[peternewman]

Sorry for not replying! And thanks for a reminder.

No worries.

Maybe it is a regional issue but in Poland footway very often changes sides with cycleway. Answering such quest would require splitting way multiple times.

That would be the same as the surface changing over it's length though.

What worse, quite often you have cycleway with footway on both sides of it (again, maybe regional issue).

Conceptually why does it exist? Are the two footways opposite directions? Or like pavements for a bike lane? It seems OSM doesn't have the means to represent that in data either.

Given the segregated tagging doesn't deal with, or handle three things, e.g. foot/bicycle+horse, should it be excluded from StreetComplete for now to ensure duff data doesn't enter the system?

What and where should be excluded?

It seems there are two cases the system can't really handle: Thirds of a way, foot, bicycle, horse - can you actually represent which bit has which paving Half of a way combined, e.g. foot, bicycle+horse - Is there any way to flag which pair are combined?