Entrance=entrance and how to map entrance only entrances

Help and support
9

What posfixing an _only
That way it becomes entrance=entrance_only or entrance=exit_only.

2 Likes
10

And amenity=parking_exit while we’re at it. :grimacing:

11
12

If the door is connecting two buildings, what would be entrance and what would be exit building (both buildings might have other doors leading out on different streets)?

how could it be solved with entrance=exit?
Frankly in such (ultrarare) cases I would map the situation as a short way with foot:forward=yes/no tags.
Ultimately if you look at the details at the transition „point“ from one building to the other you will find that it has some length, varying from few centimeters to maybe a meter (thickness of walls and doors).

1 Like
13

oneway:foot=yes

not desirable „troll“ tagging because oneway never applies to pedestrians, so a subtag of oneway shouldn’t either. Use foot:backward=yes instead

14

I did update both wiki entries.

Also checked taginfo, that was down yesterday evening.

Used in combination with entrance:

  • 23111 - exit=*
  • 1575 - on highway=footway with oneway=yes
  • 297 - direction=*
  • 181 - on highway=footway with oneway:footway=yes
  • 164 - opening:direction=*
  • 28 - on highway=footway with oneway:backward=yes

For reference:

  • 10073 - entrance=exit
  • 1392 - entrance=entrance

Checking highway=footway + oneway:foot/foot:backward=yes took more time

Did run a script to get the "way with oneway:footway/backward" numbers 
osmium tags-filter planet-2023-04-24.osm.pbf w/oneway:foot -o foot_oneward.opl
osmium tags-filter planet-2023-04-24.osm.pbf w/foot:backward -o foot_backward.opl
grep 'entrance=' foot_oneway.opl | wc
grep 'entrance=' foot_backward.opl | wc
15

It wouldn’t. oneway:foot=yes which I suggested as better alternative would.

Basically, whole of entrance=* is a mess, trying to shoehorn at least four orthogonal things into one single tag [click to expand]
  • direction: entrance/exit/emergency
  • access restrictions: main/service/emergency
  • preference: main/secondary/emergency
  • usage: garage/shop/staircase/emergency

Such attempt is bound to have problems.

entrance=* probably should’ve better not been invented, and use barrier=door (or other like barrier=turnstile etc.), with extra access tag if restricted (e.g. entrance=service should’ve been barrier=door + access=delivery), and other tags to define priority/preference if needed.

But it is what it is, it’s kind of too late to try to redefine it now…

I disagree with such definition (and conclusion drawn from it).

  • Troll tagging is about adding “additional” tag which completely changes the meaning of “primary” tag. Example given is clear: adding involuntary=yes is a trolltag, because it changes tourism=hotel completely to mean amenity=prison instead. It is not a situation here, here we have only one tag (oneway:foot) with clear meaning.

    I would agree with you, if one instead suggested using oneway=yes with additional tag direction_restrictions_do_not_apply_to_vehicles_but_to_pedestrians=yes: than that second tag would indeed be trolltag as it would attempt to change the meaning of oneway=*.
    The purpose of avoiding trolltags is that the data consumer that does not process (or even fetch!) extra attributes, would not be mislead into gaining opposite meaning of primary tag that it does fetch/process (and would instead just lose some details/precision). There is no such danger by using oneway:foot=yes, so it is not a trolltag.

  • it is clearly documented at oneway:foot=* wiki in precise and unambiguous way (throughout its entire history), so there is no confusing there either for people who do read the wiki.

  • even if one looks at English language interpretation by people who have never read the wiki, it is very likely they’ll understand the intended meaning: “oh so this is the way where pedestrians on foot can only go in one way”. So it is probably not even eligible for Counterintuitive keys and values - OpenStreetMap Wiki

  • even for people who only read some wiki pages, but not others, they will understand what the combination of foot=* (restriction applying only to pedestrians) and oneway=* (directional restrictions for something) means, especially as that specific wiki page does go into explaining this specific situation.

  • there are no “subtags” really. Sometimes tag prefixes or suffixes are used to group (even vaguely) related things together, but each “final” tag have its own meaning. E.g. just because highway=* is defined as “main key used for identifying any kind of road, street or path.” does not even mean we don’t have e.g. highway=milestone which has nothing to do with that primary definition, much less that we can’t have not:highway=* or highway:owner which mean completely different things.

  • other prefixes/suffixes do it all the time - one should acknowledge that, instead of trying to insist that shortest substring match restricts the meaning of the new tag too.
    E.g. bridge=* is to be used on non-closed ways and indicates line on which traffic can be routed over a waterway or similar barrier, yet bridge:area=* is not be used for routing at all and must be used on areas (closed ways) exclusively, for different purpose entirely.
    Other cases are even more extreme - e.g. ruins:* prefix completely defy the meaning the tag would have without that prefix – good look trying to grab something to eat at ruins:shop=supermarket.

Use foot:backward=yes instead

That is possible, although order of magnitude less popular, alternative (but you probably meant foot:backward=no instead as a matching alternative to oneway:foot=yes).

But shouldn’t one, to remain consistent, then get rid of oneway=* and oneway:*=yes too and use vehicle:backward=no (and bicycle:backward=no etc.) instead?

Because using one format for some directional restrictions (oneway:bicycle=yes, oneway:carriage=yes and oneway:hand_cart=yes), but different format for other directional restrictions (horse:backward=no, ski:backward=no and foot:backward=no) is IMHO bound to be even more confusing.

4 Likes
16

oneway can sometimes apply to pedestrians on a highway=footway, just not very commonly, but routers do respect it. For example, pedestrians are obliged to go clockwise on this path around a lake (though the kids playing Pokémon Go never abide by that rule). This walkway near the security lines at an airport is for forward travel only (though I would’ve tagged it as a highway=corridor).

I’m not sure how much stock to put in the wiki’s explanation about oneway being limited to vehicles, since oneway:foot would be clearly redundant on a highway=footway.

entrance isn’t just for doors. It can also apply to entrance gates, for example at an amusement park or at a large park where roads pass through entrances. You can clarify that it’s a door using door, but mappers often imply that it’s a door by connecting it to a building area.

I’m very much in favor of this expansive interpretation of entrance, which is essential for solving the navigable point problem in routing. But I don’t think that use case could rely on the usage-based values of entrance, since they often conflict with the other values and can be inferred from connecting ways anyways.

2 Likes
17

Just to chuck in another example, here’s one half way up a cliff: Way: ‪Giddy Edge‬ (‪100550553‬) | OpenStreetMap

18

But shouldn’t one, to remain consistent, then get rid of oneway=* and oneway:*=yes too and use vehicle:backward=no (and bicycle:backward=no etc.) instead?

I don’t think this is necessary, on the contrary a lot of countries agreed on “oneway” as a restriction applying to vehicles only in the Vienna Convention on Road Traffic, which means it is universally understood in all countries that are sharing the agreement. For the rest there is the wiki (and probably similar oneway rules despite they didn’t sign all of the agreement).

1 Like
19

oneway can sometimes apply to pedestrians on a highway=footway, just not very commonly, but routers do respect it. For example, pedestrians are obliged to go clockwise on this path around a lake (though the kids playing Pokémon Go never abide by that rule).

IMHO it is an implementation bug in the router if this tagging leads to pedestrians being routed only in one directions over the way, because oneway is clearly defined as applying to vehicles only. We might discuss about “oneway:foot” but not about “oneway=yes”

2 Likes
20

If someone added a oneway=yes tag to a highway=footway, it would only make sense for the oneway tag to be for pedestrians and not for vehicles. But when the tag is on a road for vehicles, it would probably only apply to cars because it would be weird for pedestrians to be barred from walking on the side of the road against car traffic.

3 Likes
21

If someone added a oneway=yes tag to a highway=footway, it would only make sense for the oneway tag to be for pedestrians and not for vehicles.

what about highway=pedestrian? Or highway=path foot=designated?

22

It turns out both OSRM and GraphHopper ignore oneway=yes on highway=footway, but Valhalla does honor it. And as you’ve probably noticed, openstreetmap-carto also renders one-way arrows based on oneway=yes alone.

If this is an implementation bug in Valhalla and openstreetmap-carto, it’s also a problem for OSM: 28,713 highway=pedestrian/footway/steps/corridor ways have oneway=yes/-1, vastly more than have oneway:foot=yes/-1 (642) or your suggestion of foot:forward/backward=no (just 64). I did not check whether mappers have identified thousands of footways and staircases that Vienna-style vehicles are allowed to climb.

Apparently the presumption that oneway=* only applies to vehicles dates to 2009 and was retrofitted into the oneway=* documentation in 2011. I mostly have no problem with it, since otherwise we’d be constantly fighting against accidental oneways that fail to consider pedestrians walking down the street. But now we have the opposite problem of leading pedestrians down walkways in the wrong direction, sometimes precariously as in that cliffside example, because of insisting that the same rules apply to footways.

Incidentally, the conveying=* key, with nearly 24,000 occurrences, also implies a direction even in the absence of oneway=*. (It implies the opposite direction for hamsters.) But fortunately, I’ve never encountered a moving walkway or escalator that goes directly into an entrance-only door without some kind of landing in between. That would be tailor-made for an animated GIF.

4 Likes
23

I wonder who it was who added that clause to the wiki page? :slight_smile:

Maybe it does make sense to clarify that pedestrians are allowed to walk both ways on the pavement alongside a oneway tertiary (or whatever) road, but it would fail the Clapham omnibus test to think that somehow “oneway=yes” on a “highway=footway” meant you could walk both ways along it.

1 Like
24

Thanks @BaghdadiMapper for bringing up highway=footway with oneway=yes.

Yes, oneway=yes is more popular then oneway:foot=yes and I updated the stats in my previous email. It looks like the the most popular alternative apart from exit=yes.

25

highway=pedestrian oneway=yes to mean oneway just for vehicles is actually fairly common (those vehicles that are allowed on the street at all). From what I’ve seen these are signed just like other oneway streets so it’s natural to tag them as oneway=yes when you see the sign, instead of something like oneway:vehicle=yes or oneway=yes plus oneway:foot=no.

That is what my bug report in Valhalla was about.

A sophisticated router might realise that in highway=footway oneway=yes, the oneway tag was probably meant for pedestrians… though it seems to me like this guessing game can quickly get complicated: how do you interpret the oneway tag if the highway=footway also has bicycle=yes or designated? What if it’s a path instead? A cycleway?

3 Likes
26

I stand corrected. Make that a mere 16,527 highway=footway/steps/corridor to fix and a bunch of mappers and software developers to convince. :grimacing:

To me, this is no different than deciding what access=* means on a highway=footway etc. Does access=permissive open up the footway to vehicular traffic? How about oneway=no? I think there’s a mode of transportation inherent in a tag like highway=footway, part of its essence that can’t be troll-tagged away so easily using a more general access tag.

1 Like
27

it’s also a problem for OSM: 28,713 highway=pedestrian/footway/steps/corridor ways have oneway=yes/-1, vastly more than have oneway:foot=yes/-1 (642) or your suggestion of foot:forward/backward=no (just 64). I did not check whether mappers have identified thousands of footways and staircases that Vienna-style vehicles are allowed to climb.

at least for pedestrian it is very likely correct mapping and applies to vehicles on these pedestrian streets, is regularly signposted etc. Oneway on a pedestrian road is a typical situation.

28

I did not check whether mappers have identified thousands of footways and staircases that Vienna-style vehicles are allowed to climb.

yes, 3000 out of 1.5 million highway=steps have a oneway=yes tag, there are also 9000 conveying=yes on steps, maybe the oneway has to do with it and is intended in this way.

What would we gain if we decided that oneway=yes should sometimes apply to pedestrians, as opposed to saying it should never apply to pedestrians? Wouldn’t evaluating this become a nightmare? E.g. someone changing the highway from pedestrian to footway would also significantly change the usability for one direction for pedestrians, if there was also a oneway-tag.