Entrance=entrance and how to map entrance only entrances

Help and support
1

The tag entrance=entrance is mentioned on the entrance wiki entry, but it doesn’t have its own wiki page, JOSM and mapnik don’t recognize it. So the question is, is there a better supported way to tag entrance only entrances?

3 Likes
2

I think entrance=entrance is a strange tag, the current description says:

It is an entrance only, it is a one-way in to a building or enclosed area. You find it at some larger shops, museums or theme parks.

So a “oneway” entrance.

Then my first question would be how to map a one-way exit? Next question is how to map a main/secondary/service one-way entrance.

For me it would make much more sense to use one of the other entrance tags together with a either direction=forward/backward or use entrance:forward/backward=

3

I’ve added a basic wiki stub. If someone has a picture, it would be nice.

Other than that, it seems to be exactly what you want. If you think it needs more love, you should lobby the data consumers like JOSM and mapnik (Carto?) to support it.

As noted in that new wiki page, the other way to map it might be to use oneway:foot=* on a way leading to an entrance to indicate direction in which entrance can be accessed.

1 Like
4

It is said on that same page: as entrance=exit (and yes, it has even more of confusion in the name, but it is being used as such). As for other questions, see my previous message about alternative way to tag it (already documented and in use).

2 Likes
5

That is an even better idea to me then using the direction key or :forward/backward and takes care of my second question. I think it would not be bad idea to update te Wiki to propagate using this instead of entrance=entrance/exit.

1 Like
6

I’ve added links to Tag:entrance=entrance - OpenStreetMap Wiki and Tag:entrance=exit - OpenStreetMap Wiki - feel free to improve on it; it’s a wiki!

2 Likes
7

Then my first question would be how to map a one-way exit? Next question is how to map a main/secondary/service one-way entrance.

I think the simple way is
entrance =yes/no/main/etc.
exit=yes/no/etc.
both on the same node.

If one is missing, I would expect a missing exit-tag to mean yes and a missing entrance tag no.

I would deprecate entrance=exit

1 Like
8

While it might seem easy on simplest cases (e.g. a road connects to the building), it becomes problematic on things which are not so clear about direction. 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)?
Or if outside between two pieces of land (or underground, connecting two tunnels) there is turnstile going in one direction only, what is entrance and what is exit? What if one leads to plane and another to train, what is entrance and what is exit?

I’d rather prefer adding a simple way with oneway:foot=yes leading to that entrance as unambiguous and clear solution for marking that minority of one-way-only doors/turnstiles/whatever.

Well, if I had time machine, I’d like to deprecate more than 50% of the entrance=* values, not just exit. Nowdays however, I have at least 10066+ reasons (and growing daily) not to deprecate entrance=exit.

I think my default reply to sentences containing word “deprecate” in OSM context should be “And how many months of your life are you willing to dedicate solely to accomplishing that suggestion in a reasonable way?” Just to put expectations into realistic frame… :smiling_face:

4 Likes
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