Tagging kerbs on crossings

General talk Tagging general discussion
11

Thanks everyone for your comments. I have reported this as a bug in the iD issue tracker.

Eventually I hope to have time to summarise the results of this discussion to the Wiki, which doesn’t explain the current tagging practice.

1 Like
12

Yesterday had 130 odd warnings on my Osmose listing added of “barrier blocking highway” and “barrier blocking major highway”. After a half dozen sample visits, they all appear relate to marked crossings mapped as node and line, where the editor/preset asks what kind of kerb there is (StreetComplete does/did too), and then later on getting a thank you for having added N tags that would help walkers/wheelchair users.The new Osmose warning includes even if the crossing kerb has the =flush subtag.

Today I got another few more, looked, barrier=kerb + kerb=flush included, the crossing doubles as cycleway crossing. Not sure to whom this barrier blocks forward on, but since drawn as line, certainly does not block cars as the kerb tag is only on the end nodes where it connects to the foot/cycleway, which is behind a kerb separating cycle/foot from motorised traffic.

13

Please - just ignore Osmose here. It’s clearly just wrong.

To be fair, the front page of Osmose does say “In no case Osmose-QA should provide you the absolute right way to map, always keep a critical eye”. I’d suggest that people who are “OSM completists”** should never use Osmose, because it is not the tool for them.

** they want to remove every “warning”, regardless of whether it is an error or not.

2 Likes
14

LoL, had not read that qualification before, and I am one too. Just sound-boarding. Though what is sent as warnings because ‘once upon a time’ I created / edited an object’, the Osmose map itself allows substantial filtering out specific object issues, plus only looking at pins that related to myself in the history, squeaky clean it looks. This one has been added to the no-show and gets the X treatment when showing up in the personal list. ;P)

15

And Osmose is systematically wrong in many cases, Osmose complaining is not a very strong indicator that tagging is wrong.

You can also report this problem to Osmose authors if you want.

3 Likes
16

Thanks, this is interesting. So iD complains when kerb= appears without barrier=kerb and Osmose complains when barrier=kerb appears on a road? This risks creating a lot of very slow edit wars between people who fix the tagging with Osmose and those who “fix” it with iD.

I would actually suggest that we mass remove barrier=kerb from all barrier=kerb kerb=raised nodes where the barrier=kerb was created_by iD after an earlier changeset created_by StreetComplete added kerb=raised. But as long as iD (and possibly other validators?) suggests that kerb=raised alone is a mistake in this situation, such a one-off re-tagging would just be slowly undone again, over time.

By the way, since I created this thread

  • I have updated the Wiki documentation for barrier=kerb and kerb= to better reflect current tagging practice
  • It has been pointed out that barrier=kerb kerb=lowered sometimes appears legitimately on roads in Germany. (This doesn’t block cars from using them but signals to drivers that they have to give way.)
  • It has been discussed on the German forum that OSRM won’t route cars over barrier=kerb except when either kerb=lowered or kerb=flush or highway=crossing is also present on the node

In short, the behaviour of StreetComplete + iD is slowly breaking car routing in some areas for routers (such as OSRM) that avoid barrier=kerb kerb=raised. By my estimate about 3,000 nodes worldwide are affected. I see three ways out of this dilemma

  1. StreetComplete could a different tag than kerb=raised to say that a potential crossing has been surveyed and the kerb is high - I have suggested this to @westnordost
  2. iD could stop adding barrier=kerb (see my iD bug report)
  3. Routers could ignore barrier=kerb altogether (as has been suggested in this OSRM bug report)

My preference would be for solution (2) but I don’t know how the iD programmers - presumably volunteers - prioritise bug reports. I invite everyone who agrees to “thumbs up” the Github issue, or, even better, to have a look at the code so we can create a pull request. I briefly tried this but I have no idea where to start. (I’m not even sure if the problem is in the iD code itself or in the iD tagging schema.)

2 Likes
17

wholeheartedly agree, unfortunately reality shows this is wishful thinking and completists are generally attracted by such QA tools

1 Like
18

Then let’s report this as a bug in Osmose?

Do you have an example location?

1 Like
19

The pair on one crossing.

Feel free, not me.

20

Yet, again, the barrier=kerb should be mapped at the exact position and I doubt that they are at the intersection of the two ways but rather shortly before/after the intersection only on one way.

21

May very well be but that’s not where certain software puts them completing a quest not to speak of crossing mapped as simple nodes.

22

It seems that it is caused by id-tagging-schema/data/presets/barrier/kerb at main · openstreetmap/id-tagging-schema · GitHub

So maybe better place to report it is at Issues · openstreetmap/id-tagging-schema · GitHub (and I would try to significantly shorten it, current one is extremely long and maybe could be shorter)

1 Like
23

Thanks. Now reported (without all the background) at iD recommends adding barrier=kerb to kerb=* when it shouldn't · Issue #858 · openstreetmap/id-tagging-schema · GitHub

1 Like
24

(related topic: Improving the Wiki documentation of barrier=kerb and kerb=* - #28 by westnordost )

  • StreetComplete could a different tag than kerb=raised to say that a potential crossing has been surveyed and the kerb is high - I have suggested this to @westnordost

But which tag could be used? To summarize the current state:

StreetComplete asks for intersections between footways and road-ways if there is a crossing. It’s a reasonable assumption that there might be a pedestrian crossing and not just pure coincidence that footways branch off from the road on both sides at exactly the same node.

If there is a crossing, the app adds highway=crossing.

If there is no crossing,

  • it cannot add crossing=no because crossing=no should only be used if crossing the road here is either not possible or not legal. (This has been documented as such since 2008)

  • It cannot add highway=crossing + crossing=unmarked because a (vocal) part of the community understands that this tag should only be used on crossings that are designated in one way or another as a crossing, at the very least through a lowered kerb

  • hence, the compromise has been to add kerb=raised in such case (without barrier=kerb). It was the result of a long discussion in the old German forum.

Going forward, it could tag something else in the future. I see two options so far:

  1. Reconsider using highway=crossing + crossing=unmarked in such a case. Reasons that speak for this:

    1. Even if a crossing is completely unmarked and not designated in any way, when a footway crosses the road at this point, it is pretty much an informal crossing, like in this example here. Hence, for (router) applications that evaluate crossings, they might want to treat it the same as an unmarked crossing anyway

    2. In (some) areas where sidewalks are mapped separately even in residential areas, it has become common practice to add a highway=crossing + crossing=unmarked at basically every street corner, even if there is nothing in terms of designation or marking as a crossing, i.e. even sometimes no lowered kerb

    3. The iD editor still (AFAIK) suggests to add a highway=crossing to every intersection of a driveway with a separately mapped sidewalk. Subsequently, this crossing is tagged with crossing=unmarked. According to those voices from the (old) German forum, this is also not correct. But this feature exists for so long already, it has become somewhat of a de-facto mapping

  2. Use a different tag that does not conflict with iD editor preset suggestion rules. I think somewhere kerb:both=raised was proposed. What speaks for this is that it does not stir any disagreement in what does and what doesn’t count as a highway=crossing + (crossing=unmarked)

Edit: I currently tend towards option 2 though, or alternatively change nothing, as I understand that the suggestion has been removed from iD?

3 Likes
25

Thanks for your reply!

Yes, as of yesterday, the suggestion to add barrier=kerb to all kerb=* nodes has been removed from iD (the change isn’t live yet on openstreetmap.org). This makes the issue less pressing (though it doesn’t change the fact that kerb=* as it’s currently used has multiple different meanings and I imagine it’s hard for data consumers to distinguish between them).

Also, we’ll still need to deal with the existing nodes tagged barrier=kerb kerb=raised that really should not have this kerb tag. I’m planning to propose a solution this weekend.

26

Should be possible to find these with overpass, so one could make a maproulette challenge with that.

27

Thank you for being open to changing the current behavior. I agree that adding highway=crossing + crossing=unmarked might not be the best approach. I actually took the time to read through the arguments of each side and it’s clear that neither crossing=no, nor crossing=uncontrolled would be a perfect fit for what you’re trying to say.

The only problem I’m having with keeping kerb=raised or changing to kerb:both=raised is that I’ve seen this being used for continuous sidewalks as well. Like these: https://www.mapillary.com/app/?lat=52.386810192105&lng=9.8347730700332&z=17&pKey=1197415660687010&focus=photo
This used to be tagged with simply kerb=lowered and nothing else (and in this case the meaning was: kerb from a car’s perspective, not from a pedestrian’s), because it’s technically not a crossing of the footway over the carriageway, but rather the other way around. And that way going over there is by no means a highway=service or even a driveway.

There aren’t a lot of cases like this I suppose, but someone came up with a wiki page how to map these and this is probably the third possible answer to “is there a pedestrian crossing”. I found a few dozen of these over here, so maybe, while working on that bit of SC, you want to consider this as an answer as well. The number of these “crossings” is increasing lately, because it slows down traffic immensely.

28

That is a real problem. So far, I have always looked from a pedestrian perspective and then it would be kerb=no. Maybe it is worth mentioning the perspective in the wiki at least in connections with highway=crossing.

In case of detailed mapped areas with sidewalks and cycle-tracks as separate objects the best solution is to tag the barrier=kerb, kerb=* node at the exact position only as child of one way or end/start node of a maximum of two ways.

Please, do not use :left, :right or :both on nodes. Nodes do not have any direction. :both just lengthen the key and the other two only work in conjunction with a single parent way and lack support in editing software. If you are eager to support different values per side, cardinal directions might work.

29

There is also some 900+ uses of crossing=unknown (its wiki says its deprecated because “Unknown properties do not need to be tagged”, but this may be the exception that proves the rule :thinking:)
(also note that contrary to what that wiki page claims, its deprecation is not documented at Deprecated features - OpenStreetMap Wiki)

Alternatively, there is also some few hundred uses of crossing=informal (although yet undocumented) which might fit better than crossing=unmarked (which, as noted, some people demand is only for designated crossings)

1 Like
30

I like crossing=informal, but I would not use it together with highway=crossing, since that describes “[…] a designated street crossing for pedestrians, cyclists, or equestrians”. crossing=no is also to be used without highway=crossing, so maybe crossing=informal can be the same? It would actually make sense.

On the other hand, there are crossing ways that are neither informal crossings nor official ones nor forbidden. An example would be 2 footways/paths connecting to a busy road, but only to the road’s sidewalks. So while you might theoretically be able and allowed to cross the street in countries where jaywalking is laughed about, you certainly don’t want routers to route over these. Factually, there is no crossing there, so crossing=no would feel like the right thing to use. Even though most people associate crossing=no with “forbidden to cross”, I’d like to point out that the wiki says “Tagged at nodes where it is not suitable […] to cross” and that describes the situation pretty well for me. I know this is a recent addition, but the example this comes from is from 2012, so not that new at all.

So TL;DR: I think we could use both, crossing=informal, and crossing=no (both without highway=crossing), depending on the situation.

1 Like