barrier=handrail should be hidden when combined with indoor=*

[ManDay]

I would expect indoor features to be hidden on osm.org, and for the most part they are. But then there seem to be a few which show through to a possibly unpleasant effect (when there are multiple indoor levels, it certainly becomes).

For example, this building has extensive indoor mapping, most of which is filtered out, but a handful of features defies the filtering, such as these handrails.

[polarbearing]

Strangely barrier=handrail is in the positive list in project.mml:

(CASE WHEN barrier IN ('chain', 'city_wall', 'ditch', 'fence', 'guard_rail',
                    'handrail', 'hedge', 'retaining_wall', 'wall') THEN barrier END)

This is a strange tag where being a barrier is being disputed, it's flagged as 'proposed' w/o a proposal, usage ca 6K.
Can we change the title of this issue to "Hide barrier=handrail", otherwise it is too unspecific what indoor features it is about?

Was discussed in #1986

[ManDay]

Just in that building alone there appear to be at least a few other features (all of different type) which pertain to pure indoor use and are marked indoor, yet are rendered. That's why I kept the title generic, although not all of them are necessarily a mistake. Some examples:

• https://www.openstreetmap.org/way/809644478
• https://www.openstreetmap.org/node/5224423750
• https://www.openstreetmap.org/way/809644482
• https://www.openstreetmap.org/way/809651104
• https://www.openstreetmap.org/way/809651097

(there is also this door which is rendered, however, I suspect a mapping error at this point, because no indoor tag has been set).

[HolgerJeromin]

Indoor steps should probably mapped different. Like this one https://www.openstreetmap.org/way/305821915 from me.
But your steps are free in the room (I know the building, left Aachen 5 years ago :-)).
ref
https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Modelling_connections_between_different_levels

Image: https://www.michaelrasche.com/alben/carl/inhalte/carl-hoersaalzentrum-der-rwth-aachen-6/lightbox/

[HolgerJeromin]

Your toilets should probably get an access=customers. FIXED
shop=kitchen is clearly wrong. (At least if "Haus der Küche" did not opened a new subsidiary there :-). FIXED
food_court should probably merged with the cafe or should get a fast_food instead. FIXED
cafe is rendered here on purpose (perhaps needs an access=customers, too, but would not change rendering).

[ManDay]

Ok, I'll take your word for it at this point. I know the building, too (also from back when you could still see the guts of it during construction 😄 ), but these are not my edits and I'm unfamiliar with indoor mapping. I just came across it while checking out what indoor features had been mapped on OSM. Handrails it is, then.

[jeisenbe]

This tag is clearly in use by mappers, with steadily increasing usage since 2015 and a faster increase since 2019, perhaps when it was added to iD and JOSM presets? And it is used in 15 other projects.

https://taginfo.openstreetmap.org/tags/?key=barrier&value=handrail#chronology

Usage is somewhat widespread, though concentrated in Europe still:

Description is "a rail that is designed to be grasped by the hand so as to provide stability or support. Usually found alongside steps” and the image suggests this is mainly for outdoor handrails along steps or along the edge of footpaths where they serve as a kind of pedestrian guardrail.

Reviewing usage in Hamburg, Wales, Japan, Luxembourg, and Paris, most examples are actuallly between a sidewalk and street, or a path and a water body or step slope, and are meant to keep pedestrians out of a certain area. The only indoor example was at a train station in Paris, out of several dozen which I checked.

While these are not as hard of a barrier as a tall wall, they are an obstruction to people walking upright, as well as people in wheelchairs and bikes, similar to a moderate-height fence.

So, the current rendering (same as fences) is reasonable.

[ManDay]

I do not understand your reasoning @jeisenbe. First of all, I think the fact that the OSM wiki portrays outdoor examples might be owing to the simple fact that indoor mapping is still somewhat rare and came later than outdoor mapping; the depictions are in that sense in no way normative, whereas the textual description is and extends to indoor handrails just as well.

Second, I can not make the connection between your argument (yes, they are indeed an obstruction) and the issue that these indoor features are shown on the outdoor map.

Why do you say that

the current rendering […] is reasonable

when they are rendered where they should not be rendered?

[pnorman]

For example, this building has extensive indoor mapping, most of which is filtered out, but a handful of features defies the filtering, such as these handrails.

There is no indoor filtering except for building=entrance

[ManDay]

I feel like we're not on the same page here. Perhaps my terminology doesn't match, but please understand the point that I'm trying to make: Plenty of (indoor) features such as rooms (which are visible on dedicated indoor pages like here) are not shown on OSM.org. as they should. But barrier=handrail features do show, and to an undesireable effect, as illustrated on the initial screenshot.

[imagico]

We make rendering decisions based on the tagging of features. This issue requests not rendering barrier=handrail any more because it is counterproductive when used for mapping indoor features. However as @jeisenbe has pointed out this tag is used broadly also for outdoor features (it seems even predominantly so).

If you want to propose not rendering barrier=handrail only under specific circumstances which indicate it is used for indoor handrails you would need to say what tags that decision should be based on. indoor=* would be obvious but there are less than a hundred features with barrier=handrail + indoor=* at only three locations in the database right now with that combination of tags which does not really warrant a dedicated rendering rule IMO at the moment.

[ManDay]

If you want to propose not rendering barrier=handrail only under specific circumstances which indicate it is used for indoor handrails you would need to say what tags that decision should be based on.

I have to wonder how there remains any unclarity on this. I think the whole thread (title "barrier=handrail should be hidden as indoor feature") made this amply clear, don't you?!

I can't say whether or not only a few occurences and thus erroneous renders of barrier=handrail w/ indoor=* warrant a dedicated rendering rule. I only meant to report the problem; what upstream decides to do with it is beyond my opinion or judgement.

I had originally reckoned (thus the original title) that by a single rule hiding all indoor=* features would be the obvious solution. At this point, I'm honestly fairly confused by all the contra and I'm afraid there is not much more I can contribute to this discussion. Of course it's your prerogative to decide that it's a WONTFIX!

[imagico]

I changed the issue title to clarify the suggestion.

As said for barrier=handrail use in combination with indoor=* is at this time very rare so such a change does not seem advisable at the moment. If there are other dual use indoor/outdoor tags where this is different would deserve looking at.

[matkoniecz]

Right now worldwide use of barrier=handrail indoor=yes is used 53 times worldwide, in a single mall: https://overpass-turbo.eu/s/12Vo

https://www.openstreetmap.org/way/809680917 is marked as barrier=handrail + indoor=wall - what it is supposed to be representing?

barrier=handrail with any indoor tag is used 82 times, in 3 locations worldwide: https://overpass-turbo.eu/s/12Vr

Any barrier with any indoor tag is used 2482 times worldwide: https://overpass-turbo.eu/s/12Vt

Many of this uses are barrier=wall indoor=yes what seems like a tagging for renderer and therefore I would consider to treat indoor!=no as reason to remove rendering of barrier.

[HolgerJeromin]

https://www.openstreetmap.org/way/809680917 is marked as barrier=handrail + indoor=wall - what it is supposed to be representing?

I think this should probably better indoor=fence for the balustrade (comparing its position on the image and a bit local knowledge):
https://www.michaelrasche.com/alben/carl/inhalte/carl-hoersaalzentrum-der-rwth-aachen-6/lightbox/

[ManDay]

Many of this uses are barrier=wall indoor=yes what seems like a tagging for renderer and therefore I would consider to treat indoor!=no as reason to remove rendering of barrier.

@matkoniecz To be honest I still have not understood why rendering isn't conditioned to indoor=* alltogether. Are there indoor features which should be rendered? And if yes, aren't these the exceptions which should be discussed on an individual basis?

[matkoniecz]

Currently indoor tag is not used at all.

Are there indoor features which should be rendered?

Shops, offices, railway stations, subway stations, bus stations, parking, other amenities etc etc

[ManDay]

Thank you @matkoniecz, I've been looking at a few type:way indoor=* examples and, for me, this raises a more general question about why the indoor features of the building introduced in the opening post should be hidden at all.

I.e. why should this train station have its mapped interior show on OSM.org but our building should not?

Why are only the handrails shown; shouldn't rather everything be shown, like for the train station? I do not think it should be, but I fail to recognize a comprehensible rule behind this.

What I'm trying to say in short is: How can this be resolved consistently if the above suggests that a barrier=handrail && indoor=*, wall or yes should be shown as part of the trainstation (where other inside stuff is mapped), but not inside of the building (all of which other inside features are supposed to be hidden)?