Even de StreetComplete change bekeken, meer specifiek de StreetComplete wijziging van @Tjuro:
De bovenste zijn niet 100% fout maar surface van asphalt naar paved en smoothness verwijderen is gewoon 100% fout.
1 Like
Given these tags, looks correct to me.
Or well, at least not a bug in StreetComplete but deliberate behavior. (For more information see the mentioned StreetComplete tickets. But in a nutshell:)
As I wrote, the way in the screenshot is interpreted as a segregated foot+cycleway with an additional sidewalk. For segregated foot+cycleways, the surface of the two segregated parts can be different, and if it is, it makes no sense to specify the smoothness in smoothness (because to which of the two does it refer to?)
Anyway, since this interpretation is probably not what the author (the one who tagged it) intended to express, the solution is to remove segregated=yes, or more broadly, search via overpass where else this tag has erronously been added.
Today I did some streetcompleting, and even though the cycleway had a surface of asphalt it showed a red colour on the surfaces overlay and the question about surface on the cycleway was still present.
It should not matter if there is or is not a separated= present on a cycleway. Adding cycleway:surface on a cycleway does not make sense.
These kinds of tags should only be present on highway=path
1 Like
highway=path + foot=designated/yes + bicycle=designated == highway=cycleway + foot=designated/yes
This is how all big editors interpret it, AFAIK. See also
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway#Examples
If I understand correctly, it was red because the surface of the footway-part of the foot+cycleway was not specified.
So, the thing is that i have street complete always in surface overlay mode, as I think that that is important, and I actively check and add surfaces.
I was under the impression that the cycleway in question did not have a surface tag. However it did.
After completing the chalange the surface tag was changed from asphalt to paved. However the cycleway is an asphalt cycleway.
Yes, well, the problem is the segregated=yes tag on the way(s) in question.
Do you understand why this is an issue?
1 Like
So you think changing surface=asphalt into surface=paved is correct?
The main tag is highway=cycleway, only if you do not see that this way there can be doubt.
Are you also removing smoothness from highway=residential + sidewalk=left?
In the Netherlands we have 16376 highway=cycleway + segregated=yes
Off those 11396 or roughly 70% also have a sidewalk= tag.
I think that it is a problem if at least in 11396 cases street complete has the posibility of incorrectly informing mappers and or removing correct data.
Is there some solution that you can think off to fix this issue, that does not revolve arround us checking 16376 items?
Hmm, you are on a slightly different trajectory here. This is not at all about sidewalk.
As documented in the wiki, these two tag combinations should be interpreted as the exact same feature type by software:
-
highway=path + bicycle=designated + segregated=yes -
highway=cycleway + foot=yes + segregated=yes
A segregated foot+cycleway
.
It is moot to discuss which part would be the âmain partâ of this map feature. We have to acknowledge the fact that âa segregated foot+cyclewayâ is actually two adjacent paths tagged on one way, i.e. two map features in one.
We need a consistent method how to define properties of these two parts independently, and in this case it is simply footway:* and cycleway:*.
For example:
cycleway:width=2, footway:width=1.5. You must use cycleway:width in this case here to refer to the cycleway part, regardless of whether it is tagged as highway=path or =cycleway because width=2 would refer to the way as a whole.
Edit: Also, to clarify, this does not apply to highway=cycleway + sidewalk=yes because here sidewalk is really just a property of the cycleway and not âtwo map features in oneâ. width also refers to the âcurb to curbâ width. Width of sidewalk is defined via sidewalk:<side>:width. No issue at all here.
Now, this is an interesting side-topic, but this is not the issue. The issue is that StreetComplete, or probably any other software that understands what a âsegregated foot+cyclewayâ is, interprets the way from the screenshot as such a path while in reality, it likely isnât, but a âcycleway with a sidewalkâ.
I say, this is a tagging error. In fact, a systematic tagging error committed in mass, looking at Overpass. How come that it has been tagged that way? Maybe there is some (Dutch) documentation that suggests this? Or maybe Dutch mappers have been aware of possible problems with software interpreting sidewalks on cyclways, so they added segregated=yes âfor backward compatibilityâ? This is most important to find out, otherwise it could just turn out to be a continuous problem instead of a one-time fix.
So, to reply to @Tjuro: I think these should still be fixed. If StreetComplete somehow understood âwhat the mapper intended to expressâ, it would not solve the issue. Other software must be able to interpret this data correctly, too. So, yeah, maybe a MapRoulette task would be best.
A âfixâ in StreetComplete would be to generally discard the possibility that foot+cycleways with an additional sidewalk can exist in reality and hence ignore any segregated tag if there is already a sidewalk tag. But that would be just incorrect, they can exist (otherwise, you could just remove segregated=yes from all these ways without checking). (Do you follow?)
Iâd not be very happy about this, but I guess one thing you could try to do instead of fixing occurances of highway=cycleway + foot=yes + segregated=yes + sidewalk=yes + ... is to seek consensus (on the global forums / tagging mailinglist / via a proposal) that the above should always be interpreted as âcycleway with sidewalkâ and never as âfoot+cycleway with sidewalkâ.
I would not be happy about it, because this would mean that it would be impossible to tag a âfoot+cycleway with sidewalkâ, i.e. it would be impossible to tag a situation that may very well exist on the ground. On top of making cycleway+footway tagging parsing even more complex for software.
Sorry for the wording, I did not mean that SC messes things up by itself, I donât think it does, and we should just look for the cause of the unwanted tagging which - for whatever reason or cause - is created by users of SC. Your analysis and explanations help a lot!
Iirc, from other threads. segregated=yes was added in the past to silence the editor. So it would indeed be a good idea to systematically remove this tagging, imho.
Agreed. segregated=no is fine on the cycleways without any sidewalk or segregation, but any cycleway with an inclusive sidewalk-value (e.g., sidewalk=left, sidewalk:left=yes, sidewalk:both=yes, etc.) could be cleaned up and have segregated=yes removed. I still consider this a StreetComplete-bug though; cycleway:surface should not be used when sidewalk is set.
@westnordost Semantically sidewalk=trueish implies segregated=yes, and having segregated=yes there should effectively be the same as omitting it. (Conversely, segregated=yes of course does not imply that there is a sidewalk, although that is possible, just that the cycleway and footway are segregated by something.)
There could of course be a hypothetical shared cycleway/footway with an additional sidewalk on the side (so two footpaths), where you would actually need a segregated=yes and a sidewalk=trueish to mean the two different (weird) footpaths, but if these even exist just mapping that rather unique sidewalk separately will save everyone a lot of headaches.
1 Like
It seems to me that the two cases can be distinguished by the foot access tag. In the âDutchâ situation where the cycle path and the sidewalk are two separate OSM ways, the cycle path would get a foot=use_sidepath or foot=no.
In the âGermanâ situation where a single OSM way is use for both the cycle path and the sidewalk the tag would be foot=designated or foot=yes.
Obviously, if a way has tag foot=no or foot=use_sidewalk, there should be no `sidewalk:* tags and no cycleway:* tags.
That is only for separately mapped sidewalks. More common is highway=cycleway with sidewalk=left|right. Both approaches are valid. The absence of a trueish sidewalk or sidewalk:* value distinguishes between the combined foot/cycleway and the cycleway-with-a-sidewalk (typical in the Netherlands, but not exclusive to our country either).
Even checken:
Dus deze zou kloppen:
Er stond cycleway:surface=asphalt, dat heb ik veranderd in surface=asphalt want het object is de cycleway dus daar slaat de tag op. Idem met width.
En geen segregated tag want sidewalk=yes betekent dat er een trottoir naast ligt en het fietspad zelf is alleen voor fietsers.
Juist?
Aangepast: sidewalk=left, en sidewalk:left:surface=asphalt ipv footway:surface=asphalt
De footway:surface moet nog weg. Die zou je kunnen vervangen door sidwalk:<side>:surface.
En het zou beter zijn om de kant van de sidewalk aan te geven. Dus sidewalk=right, sidwalk=left of sidewalk=both
1 Like
Indeed, thatâs a third case, which should not be confusing. As long as all cases can be clearly distinguished, there should be no need for confusing mapping.