Talk:Tag:barrier=wicket gate

Wicket gate integrated into a larger gate

In practice, a wicket gate (small pedestrian gate) is often physically integrated into a larger vehicle gate. In OpenStreetMap this situation is commonly represented by a single node on the barrier line.

However, it is currently impossible to tag both barrier=gate and barrier=wicket_gate on the same element. This leads to two recurring problems:

1. The pedestrian wicket gate exists, but the footway is not mapped separately, so there is no distinct element where barrier=wicket_gate could be applied.
2. Access and locking properties may differ between the main gate and the wicket gate, but current tagging does not allow expressing this distinction on a single node.

Proposed tagging

To describe a pedestrian wicket gate integrated into a larger vehicle gate without redefining the main barrier type, an additional presence tag can be used:

barrier=gate wicket_gate=yes

This preserves the primary function of the barrier as a vehicle gate while explicitly stating that a pedestrian wicket gate is also present, even when both share the same node.

Access and locking tags

When a wicket gate is integrated into a main gate, generic access tags such as:

access=private locked=yes

may become ambiguous, as they could apply only to the main gate, while the wicket gate may have different rules.

To avoid ambiguity, access-related tags can be scoped explicitly to the relevant gate type:

gate:access=private gate:locked=yes

wicket_gate:access=permissive wicket_gate:locked=no

This allows correct and unambiguous tagging of situations where:

• the vehicle gate is locked but the wicket gate is unlocked,
• wicket gare access differs from vehicle access through a gate,
• or both elements have independent access or locking rules.
• avoids artificial node splitting

—Preceding unsigned comment added by Yog Sot (talk • contribs) 27 December 2025

I don't see necessity of wicket_gate=* (and other barrier=*_gate ). Especially here, "Note that barrier=gate is widely used to map also wicket gates, as it sometimes isn't really clear which is which.", and " It may also be a stand-alone gate that provides convenient secondary access, for example to the rear of a walled park or garden." ( entrance=secondary ? ), meaning conflicting definitions and uses.
It only increased sharply from 1.5k in 2022, after iD added it https://github.com/openstreetmap/id-tagging-schema/pull/506
Seems mass added in 2014, and remained stagnant at ~300 until 2019 https://taghistory.raifer.tech/?#***/barrier/wicket_gate
I would simply use eg gate=wicket , gate:wicket=yes ( gate:type=* is another mess)
But is your question not motor_vehicle=private + foot=permissive ?
—— Kovposch (talk) 18:37, 28 December 2025 (UTC)

I've made the key issue bold: it is currently impossible to tag both barrier=gate and barrier=wicket_gate on the same element.. That's what it's about. you can't have wicket and a gate tagged on the same node even tho both are present. I'm not discussing to make barrier=wicket_gate obsolete, because it's use is common, iD support it and only prob is that carto doesn't render it (yet) and it still gotta be approved, hence i'm listing one of the issues to work out. --Yog Sot (talk) 14:56, 2 January 2026 (UTC)

I agree with you and haven't found a real use case for barrier=wicket_gate in the narrow sense, yet, beside the use with the historical wicket gates next to city or castle gates. The tag is used as synonym for a small (human pedestrian only) gate. One could call it a misuse of the historical term. The narrow sense of a wicket gate (beside the historical ones) is a feature (property) of a larger gate that would have to be tagged with an optional tag like wicket_gate=yes. Other gates, not integrated in larger ones, or not historical, are better tagged in OSM with barrier=gate simply, IMHO, because the purpose (access function) is the relevant thing (not the colloquial naming). --Chris2map (talk) 16:45, 2 January 2026 (UTC)

barrier=wicket_gate or a type of a gate

Okey, because there are some doubts about why not use barrier=gate for all gates and just use gate:type=* instead, first it is to make one thing clear:

• Wicket gate is not a historical term only.
• it directly translated to a gate too narrow for wide vehicles to use and not just other languages, but for english speakers as well.
• it is a proper attribute(feature) name for what best describes the function in english and english is the language for naming tags. Many languages describe it as a completely independent word without reference a to gate. So even tho english speakers may have a difficulty there, mappers speaking different languages do not.
• if a wicket gate is actually historical, then tag historic=yes is sufficient. A wicket gate is not historical by default.

So, once we can agree on that, we should consider and realise that gate:type=* does not describe for what kind of vehicles/people it is, but rather how it operates. A wicket gate can be :type

• single
• dounble
• turning
• or any other

It might be a good idea to use barrier=gate wicket_gate=separate preset instead of just barrier=wicket_gate, but yeah, better talk to iD folks fast about it, before carto will start rendering it, coz then that will be equal to approved. If the tagging would change like that, still there needs to be a tag for a wicket gate on the same `node` as the standard gate and that could possibly be wicket_gate=integrated or wicket_gate=adjacent --Yog Sot (talk) 22:45, 3 January 2026 (UTC)