I don’t want to tag it as sidewalk:both=yes as while it was technically built as one (in times past, where the car was a rarity), it is unusable as a sidewalk at all times nowadays (this picture is taken when it is less crowded), so routers would try to get pedestrians there to their detriment
I don’t want to tag is as amenity=parking, as, although it is obviously being used as one, it is incorrect and illegal, and cars will from time to time be towed away and fines charged, and I’d like to avoid being found by motorcar mob and killed
I don’t want to leave it untagged, as next StreetComplete mapper that comes along will mark it as one of the (incorrect) options above
I know these situations quite well, can also frequently be seen in some areas around here.
I would tag it as sidewalk:both=yes because this is what is there, a sidewalk. If it is hardly ever usable as such, I would add some additional tagging like “obstacle=parked_cars”, which would in this case have to be something like “sidewalk:obstacle=parked_cars” or with “:both” as well.
+1, it is not a parking, there are parked cars, which is a different situation.
By the way, there might then also be an “obstacle=pedestrians_on_the_road” required
Wanting to provide accurate info for routers is a worthy cause. Alas we’re entering possibly “subjective” defintions. How often do cars have to be parked there, etc.
OSMWiki for obstacle key says: _“obstacles which are derived … from its environment or local properties … navigation application [can use it] to avoid areas or … with lower priorities when calculating routes”.
Perhaps obstacle:sidewalk=very_frequently_parked_cars is a good tag?
yes, one might see it as “subjective”, but in some residential areas, cars are always parked on the sidewalks, 24/7, just as in some commercial areas, cars are always parked in the second row / on the street, on some streets (larger one with several lanes) in front of the stores (during business hours).
Authorities are usually aware of this, but they do not act because in the case of residential areas, there simply might not be the space to legally park all the cars that the people own, and in the commercial areas, shop owners might bribe law enforcement because they fear to loose clients if the practise was sanctioned (at least this is what I am told).
I don’t think that’s a good way to approach the situation. If there is a sidewalk and it’s meant to be used by pedestrians, can we then please tag the sidewalk as present? The fact that a car is parked on the sidewalk doesn’t make it less of a sidewalk, just less usable. obstacle=* seems to be a good starting point, because all mapped attributes are verifiable on the ground, plus routers could avoid ways with an obstacle. Good suggestion!
I asked myself a similar question when faced with a 30 cm wide sidewalk. Does it even count as a sidewalk? Probably, but just to be sure, I mapped it as a sidewalk with a width of 0.3m, because that’s the ground truth and if a router wants to make use of that information, it can.
@Matija_Nalis I think the tag parking = on_kerb would be most appropriate to represent this situation.
I don’t think it would be appropriate, parking=on_kerb is for the situation of a legal parking possibility on the sidewalk, it isn’t suitable for places where parking is forbidden but drivers do not obey
at least it could be recorded that parking is illegal? Likely a new tag is needed, but then that would likely prompt a controversial discussion about the cars not being fixed objects of true permanence, even though there might be many at any given time on the street.
+1 – The question of how to deal with irregular sidewalk parking came up several times during the revision of the street parking scheme and the majority opinion was that it should not be mapped with the regular street parking scheme. There is no documented alternative concept yet - my suggestion is to use a prefix: irregular:parking:both=half_on_kerb (instead of parking:both=half_on_kerb).
Regarding the sidewalk itself: It is also possible to map it separately as disused:highway=footway + footway=sidewalk, but at the street center line there should still be a sidewalk:both=separate (even if some applications might interpret this as synonymous with sidewalk=both). TagInfo also knows 13x disused:sidewalk if you don’t want to map it separately
I agree. I used this one intentionally as it is more versatile (e.g. left side might be protected by bollards and thus usable for pedestrians, but right side might be like original picture and not usable; also it might conceivable extended like sidewalk:both=not_usable, and/or sidewalk:both:width=0.01)
Good idea when sidewalk is still usable in same cases (one could add more popular sidewalk:wheelchair=no to it to indicate that it unusable for wheelchairs, and thus similar categories of people like parents with baby strollers, people pushing bicycles beside themselves etc).
However, I feel it would be a trolltag in this cases where it is sidewalk:both:width=0.01… Like “yeah, sure there is a sidewalk! Oh by the way it is usable only by ants”
Maybe, but I’m not too keen on inventing all other prefix for tags and trying to get all routers to implement it. I would like a solution that by default (i.e. without any change in many routers/renderers that exists) it would treat it like sidewalk:both=no; but where sufficiently interested data consumer can find out the details.
Maybe something along the lines sidewalk:both=no + sidewalk:both:note=not usable for pedestrians as it is 24/7 full of illegally parked cars
I definitely do not want to make an effort to mark separately something which is unusable
So thanks, disused:sidewalk=both might be usable alternative too.
Thanks everybody for ideas! While there are several other possible combinations / alternatives, I’ve boiled the most promising choices to three presented below. I’m wondering what would people reading this prefer (I’m personally undecided between A and C)?
sidewalk:note=not usable for pedestrians
as it is 24/7 full of illegally parked cars
pro: produces correct routing by default (i.e. does not route pedestrians there!); does not require any changes to current routers/renderers/editors/QA (easiest!) contra: while close, not really technically correct; details only readable by humans
pro: partially technically correct (but incorrect in practice); existing tags (semi-documented, but somewhat common use) contra:trolltagging; will produce bad routing by default; require changing all routers/renderers to produce wanted results (lots of work!); should better document tags
pro: more technically correct; documented (prefix) tag; produces correct routing by default (i.e. does not route pedestrians there!); does not require changes to routers/renderers contra: very-low-usage tags; require changing StreetComplete quest to skip those (only little work);