Talk:Key:wall

From OpenStreetMap Wiki
Latest comment: 16 days ago by L4PSA in topic perforated & screen_block
Jump to navigation Jump to search

Why redirect to Tag:barrier=wall

The Key wall=* is something different as barrier=wall. The key is used for tags like wall=noise_barrier

The values for wall are currently documented on that page in the "Wall details" section. Of course that could be moved here, but I find it helps readability not to split the information on how to map walls across multiple wiki pages. --Tordanik 21:38, 4 March 2021 (UTC)Reply

stone vs stone_wall

The description for stone talks about stone_wall. The pages stone and stone_wall are the same except about taginfo. Stone_wall is not a material but the mix of a material and what is built with. I think, considering taginfo for stone_wall, that we should indicate stone_wall as deprecated with stone as a better value. Krako73 (talk) 15:32, 1 February 2023 (UTC)Reply

Wall against Avalanches

See Avalanche_dam on Wikipedia.

perforated & screen_block

@L4PSA: Usually, we document tags on key description pages that have notable or accepted usage, so that they are unquestionable for use. Therefore, the two tag values recently added by you, perforated and screen_block, should be removed again from the table, in my opinion. Can you consider that? --Chris2map (talk) 20:50, 22 October 2026 (UTC)Reply

In my opinion no, because it has been discussed in the discord channel wiki-and-proposals with several members, and we have come up with these values. Removing them would make them harder to find and people could come up with their own values instead, which would make things more messy. So I think it's fine. L4PSA (talk) 20:53, 22 October 2026 (UTC)Reply
But they not used and new. If they are discussed somewhere, that is an important information and should be recognizable and provided with a documentation. --Chris2map (talk) 21:14, 22 October 2026 (UTC)Reply
Alright, sure. How do you recommend to proceed then? Just removing the values and wait till they are used? L4PSA (talk) 21:16, 22 October 2026 (UTC)Reply
That would be the standard case. The tags listed on the key page are generally "common tags / values". By this, I mean tags that are either currently in use by multiple users or have been approved. There is no prohibition against using tags. However, on a key description page, this mode serves to ensure clarity and reliability. Moreover, it sometimes only becomes apparent in practice whether a tag works; that is, whether it will be suitable and accepted.
Please describe the fact that these are proposed values ​​currently under discussion, and include a link to (or an excerpt from) the discussion on the individual tag pages. --Chris2map (talk) 21:38, 22 October 2026 (UTC)Reply
Thank you for the explanation! However I think there is no more discussion to these values because they are quite straightforward and there isn't any ongoing discussion no more unless I make a proposal page or something. Are you suggesting I should do that even for such values?
And how should I cite the discord discussion on both pages without duplicating stuff? Because it was a discussion for both values at once. L4PSA (talk) 21:50, 22 October 2026 (UTC)Reply
No, I am not suggesting a proposal process. Duplicating isn't false. But you could link the description from one to the other, e.g. something like "this tag value is proposed with discussion ..., as with further values, see [[Tag:wall=xy]]. --Chris2map (talk) 21:55, 22 October 2026 (UTC)Reply
Thank you so much! I will definitely do that (not today though). Also, when would you say it would be good to put it back on the key page, when is it considered in use or approved?
Again, thanks for clearing things up, I genuinely did not know that because nobody told me and I couldn't really find clear guide on this in the wiki.
You can remove both values for now from the wall=* page. L4PSA (talk) 22:04, 22 October 2026 (UTC)Reply
Alright, I specified that they're both proposed in both descriptions with a link. L4PSA (talk) 09:14, 23 October 2026 (UTC)Reply