Render if gates are locked or not

[SonnyLidarDTM]

Right now Carto renders a standard black icon for gates. Undependend if the gate is tagged with locked=yes or locked=no
I think this tag is an important info for the practical usage of a map, because it can people help to avoid long detours if they know that a gate is opened. Or it can avoid that people are finally ending in front of locked gates - which again can lead to long detours.
https://wiki.openstreetmap.org/wiki/Key:locked

The easiest and most unsterstandable rendering probaly is:

• if locked=yes : render icon red
• if locked=no : render icon green
• if no tagging is present: render it black like now

We possibly can think about further (=access) tags on the gate to interpret - if "locked"-Tag is missing. For example if access=no/private: render red icon, or if access=yes/permissive: render green icon

[imagico]

locked=* has 39k uses on barrier=gate, access=* 920k. So the latter is more frequently mapped and also more significant for the map user.

Hence i would not be in favor of the request as is but indicating access restrictions on barrier=gate is something worth considering.

[SonnyLidarDTM]

I think it makes sense to consider both tags the same time and not to ignore one of them. There might be some situations where locked=no but access=private . Not to mention gates which are only tagged with locked=* or access=*

[imagico]

As said - what mappers predominantly map and what we would like to show - if feasible design wise - is access restrictions on gates. I don't think anything more complex (no matter what logic you want to use to conflate access restrictions and physical status) can be done in a way that is compatible to our goals (in particular of being useful to the target map user and being intuitively understandable for mappers).

Side note: I don't usually comment on prescriptive parts of the OSM wiki here - but i consider it highly problematic that the wiki page for locked=* does not contain any warnings regarding mapping of private information. In many parts of the world private estates are typically fenced/or walled with a gate to enter and universally encouraging mappers to document the typical locking status of such gates to private homes is not a good idea. This is not something to be discussed here, just a hint at mappers using the tag.

[dch0ph]

Agree that we can't merge independent tagging, and access restrictions should be priority.

A reasonable way forward, consistent with current mapping, would be to apply the same logic of using a lower opacity for "restricted access". access=customers continues to be an awkward intermediate case for the map user, but in the absence of a general solution, highlighting restricted access would meet the goal of providing mapper feedback.

For consistency, I would suggest applying the same logic to the other lockable gate-like barriers, lift_gate and swing_gate. I don't think access restrictions make sense for turnstiles, and kissing gates are generally not lockable.

I do think the opacity needs to be less aggressive than 0.33, otherwise the restricted features merge into access marking restrictions.

[imagico]

I don't think the idea of rendering barrier symbols in a weaker form for locked or access restricted barriers is in any way intuitive. If at all a locked/access restricted barrier=* is a more massive version than one without those attributes.

Varying the symbol for access restricted barriers at the high zoom levels is an option IMO - but that is a separate issue. This one is about rendering the locked=* status. If it is feasible to intuitively depict both access=* and locked=* at the same time seems doubtful to me but this can ultimately only be decided based on a concrete design proposal.

[dch0ph]

I think the discussion shows that access and locked rendering are inter-twined, and concrete design proposals aren't going to emerge without some idea of what would be a viable / acceptable solution.

Here's an example I was thinking of:

Particularly in rural contexts, you have lots of gates with implicit private access on private tracks. The map ends up cluttered with gates. Reduced visibility of barriers with private access is here both visually intuitive and provides mapper feedback.

The logic of rendering locked is exactly the reverse: highlighting certain features. Personally I don't think this works. To be useful for the original stated purpose of route planning, this would need to rendered at low zoom (lower than the current Z17+), and be bolder than the current mapping (a bright red gate?). The discovery of a locked barrier on an otherwise open route is perhaps better handled by a router than cartographically.

[imagico]

concrete design proposals aren't going to emerge without some idea of what would be a viable / acceptable solution.

I think i have been fairly clear about that above in #4849 (comment):

what mappers predominantly map and what we would like to show - if feasible design wise - is access restrictions on gates. I don't think anything more complex (no matter what logic you want to use to conflate access restrictions and physical status) can be done in a way that is compatible to our goals.

As said already: How this might be possible to accomplish is not really a matter for this issue.

And keep in mind that an access restricted or locked gate cannot only be found on access restricted roads. It can equally be found between an access restricted road and a not access restricted road or between two not access restricted roads - like for example quite commonly between a normal road and a pedestrian road. In other words: A design for indicating access restricted gates will need to work intuitively in fairly different contexts and i don't think a lighter/faded version of the normal gate symbol is going to work for that.

The main problem with the whole idea of rendering access restriction on gates - apart from the challenge of developing a design that works for that - is, that gates are more frequently tagged with transport mode differentiated access restrictions (like motor_vehicle=*, foot=*, bicycle=*) than most roads. That means a good solution for this would depend quite a bit on #214.