unknown value icon hides other icons

[skyper]

What steps will reproduce the problem?

1. add entrance=main to a node
2. add barrier=* with an unknown value

What is the expected result?

The icon for entrance is still visible

What happens instead?

Icon for "unknown value" is displayed

Please provide any additional information below. Attach a screenshot if possible.

With amenity and tourism it works without problem. Have a look at my example file​

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-11-06 02:33:47
Last Changed Author: Klumbumbus
Revision: 7708
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-11-05 13:25:17 +0100 (Wed, 05 Nov 2014)
Last Changed Rev: 7708

Identification: JOSM/1.5 (7708 en) Linux Debian GNU/Linux 7.7 (wheezy)
Memory Usage: 309 MB / 882 MB (37 MB allocated, but free)
Java version: 1.7.0_65, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u65-2.5.1-5~deb7u1
VM arguments: [-Djosm.home=/tmp/.josm]
Program arguments: [--language=en]
Dataset consistency test: No problems found

[skyper]

osm example file

[skyper]

screenshot

[Klumbumbus]

I suggest to remove the icon for unknown barrier=* becasue it doesn't make much sense. As far as I know, barrier is the only case, where such an icon exists.

[Klumbumbus]

There are 4 solutions:

• completely remove the icon for unknown barrier=* con: loosing this icon
• keep as is. pro: would help fix typos in barrier=*. con: default mappaint style is not a validation style. see ticket:10529#comment:41
• move the complete barrier code block above the building/entrance/address code block, which would result in that entrance icons are always prioritized over barrier icons. The questions are: which combinations of barrier=* with entrance/building/address are common and which icon is more important?
• display the icon for unknown barrier=* only if there is no other fitting icon. (simple solution by just adding [!is_prop_set(icon-image, default)] to the node[barrier]rule.) con: a bit inconsistent, because barrier=* icons are always prioritized over entrance/building/address icons except for unknown barrier values.

[skyper]

• use a small additional icon like note and fixme.

[Klumbumbus]

In 8040/josm:

fix #10725 - remove icon for unknown barrier values

[Klumbumbus]

I removed the icon. We don't want to support tags like barrier=bla with an icon. JOSM has icons for the most used barrier values (for a few only the white "no_icon" icon).

There are 7765 nodes with barrier=*+ entrance=*. According to this querry ​http://overpass-turbo.eu/s/7By the most cases are entrance=* + barrier=gate. So I think it is ok to prioritize the barrier icon over the entance icon. (I think this combination is wrong in most cases anyway...)

[aceman]

Why would the combination be wrong?

[Klumbumbus]

For a door, where I enter a building I only set entrance=*. For a gate in a wall or fence I only set barrier=gate.

[skyper]

Replying to Klumbumbus:

For a door, where I enter a building I only set entrance=*. For a gate in a wall or fence I only set barrier=gate.

• How do you tag an entrance to a building with a curtain and no door ?
• How do I mark the main entrance of a fenced/walled area ?
• What is wrong with entrance=yes/garage and barrier=gate ?
• The door=* ​proposal simply drops barrier=door but sadly has some overlaps with barrier=gate or am I wrong and the last three examples are really doors ?

[Klumbumbus]

Replying to skyper:

• How do you tag an entrance to a building with a curtain and no door ?

I don't because where I live there are always doors ;) I would tag this also as entrance=yes/main

• How do I mark the main entrance of a fenced/walled area ?

I didn't say that it is always wrong.

• What is wrong with entrance=yes/garage and barrier=gate ?

I would't use barrier=gate there. For me barrier=gate is a node which is part of a linear barrier and the point where I can cross this linear barrier

...OK I revise my comment from "wrong in most cases" to "questionable in some cases"