gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.51k stars 811 forks source link

[Feature Request] Render `barrier=hampshire_gate` and other barriers designed to block access. #4941

Open dreirund opened 3 months ago

dreirund commented 3 months ago

Ahoj,

here in Italia, where I have been mapped around the location I am currently, there are many barrier=hampshire_gates and some barrier=chains, obstructing or forbidding entrance (access=private) to tracks and driveways.

On the standard rendering of the map at openstreetmap.org I see that only barrier=gate is rendered.

I hereby suggest to render also other obstructing barriers. barrier=hampshire_gate safely can be rendered with the same symbol as a barrier=gate, I suggest (in fact it is a type of a gate). But more generally, I think all barriers that are designed to block access to a way could be rendered with the same symbol.

Regards!

imagico commented 3 months ago

Thanks for the suggestion.

For barrier=chain we have #4409.

We don't want to render all barrier values with a catch-all because that does not support consistent tagging. We currently render with a point symbol:

barrier count
gate 5.2M
bollard 693k
lift_gate 477k
block 162k
cycle_barrier 125k
swing_gate 97k
stile 95k
cattle_grid 71k
kissing_gate 43k
turnstile 15k
log 11k
full-height_turnstile 2.5k
motorcycle_barrier 1.1k

barrier=hampshire_gate has 6k uses, more frequently used and not rendered are also:

dreirund commented 3 months ago

Ahoj,

barrier=hampshire_gate has 6k uses, more frequently used and not rendered are also:

  • barrier=sliding_gate - 16k
  • barrier=wicket_gate - 9.6k

Why not render all types of gates with the same symbol? I think it is less important to know which type of gate it is, but to know that there is a gate. In fact all of them are gates.

(hampshire_gate may be also be so low because it is only in some countries. Here in Italia outside of town "on the ground" it is the most common type of gate and very common, blocking access to tracks, but general mapping quality is not so well here.)

Regards!

imagico commented 3 months ago

Why not render all types of gates with the same symbol?

We currently have some differentiation in that regard - but unifying several different types with a common symbol is definitely a possibility (and already done in some cases).

When doing so it is best to keep in mind that the differences in visual appearance should reflect differences in meaning to the target map user. Rendering semantically very different features with the same design while showing similar features with different symbols does not work too well.

There is also the option to use a common symbol at low zoom levels while switching to a differentiated rendering at higher zoom levels.

dreirund commented 3 months ago

On Thu, 07 Mar 2024 02:58:13 -0800, Christoph Hormann @.***> wrote:

Why not render all types of gates with the same symbol?

We currently have some differentiation in that regard - but unifying several different types with a common symbol is definitely a possibility (and already done in some cases).

When doing so it is best to keep in mind that the differences in visual appearance should reflect differences in meaning to the target map user.

Of course, that is also what I find most important.

Regarding those gates, I think the access=* tags make much more of a meaning differentiation than what type of gate it is. At least what I encounter here in Italia, barrier=hampshire_gate, barrier=chain or barrier=gate all usually say that you shall not pass; exceptions on marked hiking trails.

imagico commented 3 months ago

Rendering of access restrictions on gates has been discussed a bit recently in #4849.

dch0ph commented 3 months ago

Based on the description of usage, there seems a good case for rendering barrier=hampshire_gate in the same way as barrier=gate; both are generally traffic barriers across a minor / road track. One is just a less "engineered" version.

I'm less convinced by using the gate symbol as a default rendering for anything described as a gate. There's so much variety that there is always going to be a tension between what is out there, and what can be represented. We already have a symbol for lift_gate / swing_gate, since these are quite distinctive.

barrier=sliding_gate looks tricky to represent.

barrier=wicket_gate is an interesting one, since it would be useful to render a "hand gate" for foot traffic. [I'm guilty of using barrier=gate on footways because it renders, rather than the formally more correct wicket_gate.] An adapted version of the gate symbol with square aspect ratio could retain visual consistency and show that the overall way is narrower.

dch0ph commented 3 months ago

On further thought, I'm confused by barrier=wicket_gate. The meaning, and wiki text, refers to a pedestrian entrance that is always a secondary entrance, either part of the larger gate (or, more mysteriously a secondary side pedestrian entrance).

In practice, mappers seem to be using it more generally for a pedestrian gate, including where only foot traffic is possible, perhaps because it has a wiki entry. A specific render would encourage misuse.

barrier=footgate is unambiguously a gate for pedestrians only, but isn't widely used (~500 uses).

TL;DR Suggest (and can provide) a PR for rendering barrier=hampshire_gate as barrier=gate, and stop there for now.

imagico commented 3 months ago

rendering barrier=hampshire_gate as barrier=gate

I would be fine with that but i also think it would be feasible to develop a suitable distinct symbol.

barrier=sliding_gate would superficially seem a candidate as well - but outside of organized mapping activities it competes with gate:type=sliding/rolling which puts rendering support into question.

dch0ph commented 3 months ago

I won't rush to a PR in case somebody has a good idea for a distinct symbol.