Currently, the wall=* key mixes the three distinct aspects of function, material, and construction method/structure (wall=noise_barrier / wall=brick / wall=gabion), creating ambiguity and inconsistent tagging.
For example, a noise barrier built with gabion baskets filled with stones (or glass) cannot be fully tagged – mappers must choose between wall=noise_barrier (function) or wall=gabion (construction method), losing information either way.
This proposal addresses these issues by:
Restricting wall=* to function only (noise_barrier, seawall, flood_wall, etc.)
Using the existing material=* key for materials (concrete, stone, brick, etc.)
Introducing wall:structure=* for construction methods (gabion, dry_stone, masonry, panel, poured, etc.)
This approach follows established OSM patterns like building:structure=*, by applying them to walls via wall:structure::
The proposal preserves all currently defined functional tags for backward compatibility, while also adding construction methods that were previously missing. Material-based and construction-method-based wall=* values will be deprecated in favor of the new structured approach.
I’d personally prefer to keep it simple with structure=* instead of wall:structure=* (similar to material=*). It seems from the Wiki that the former is only used on power=tower for now. I don’t think such a simple, general tag should be limited to that use. Electricity towers aren’t the only objects with a “structure”.
Originally, I fancied wall:construction, because construction is already occupied with a completely different meaning. The problem with these tags is, that if the meaning changes depending on where you’re applying it, then I would prefer to prefix it. I always found the service=*-page confusing, because it’s being used for completely different things. Even though it’s “only” used on power towers, structure has over 600k uses, which is why I decided against overloading it, and since building:structure is also used widely, I went for the prefixed version as well.
It would be nice, though, if we could apply the structure logic from barrier=wall to barrier=retaining_wall and barrier=city_wall as well, but I didn’t want to make that part of my original proposal.
The problem with these tags is, that if the meaning changes depending on where you’re applying it, then I would prefer to prefix it.
it is not uncommon though, you mentioned “service”, there is also “usage” and recently many contributors said “oneway” should refer to pedestrians when combined with footway but not when combined with roads or highway=pedestrian, “access” tagging on parkings is about who can park there, but not who has access, the building:levels tag has to be interpreted looking also at the minlevel (which itself has to be determined looking at nearby buildings), “network” also is used in different ways, …
I’m once again asking for your opinion. There are 3 open questions, which is why I’m creating this poll. Please read through the background first, so you don’t use your gut feeling, but are making an informed decision.
Main tag
What should the tag to define the structure/construction of a wall be:
wall:structure, to avoid disambiguity
structure, with a specific section for walls
0voters
Background:
If we use wall:structure, we probably want to use the same for retaining_wall:structure, and city_wall:structure, which is absolutely reasonable, but would need appropriate redirections in the wiki.
Using just structure collides with the current meaning of the tag, which is used for »the structure of pylons carrying high voltage electricity cables, tagged on power=tower and for catenary masts carrying overhead wires, tagged on power=catenary_mast.« The Wiki-page will have to be changed accordingly. This is not very common, but there are numerous precedents, like Key:service.
Dry Stone
Should the former wall=dry_stone be converted to (wall:)structure=*
*=dry_stone, so we have an identical value to wall=dry_stone
*=dry_stacked, which is (according to my British sources) the term a stone fitter would use
*=dry_laid, an alternative value suggested by @kovposch
0voters
Background:
I am not a native speaker, but I have a friend from London who is a stone fitter – someone who creates walls and houses without the use of mortar. He said that he would call a wall that’s created this way »dry stacked«, but ‘dry laid’ would definitely also be understandable. I don’t know if one term is British English, and the other one American English, so please use your own judgment. Note that while the result would be a “dry stone wall”, under this proposal the structure wouldn’t be called “dry stone” but would be material-agnostic."
Concrete blocks
Should wall=concrete_block be converted to:
(wall:)structure=masonry + material=concrete, because it should be clear that they are in blocks if the structure is masonry
(optional (wall:)structure=masonry) + material=concrete_block, because a concrete_block is not just a block of concrete, but a specific building material
(optional (wall:)structure=masonry) + material=concrete:block, so we are in line with concrete:lanes and the likes
0voters
Background:
Concrete blocks are a very widespread building material. They are also known as a »cinder block« in North America, as »breeze block« in Britain, or even as »concrete masonry unit (CMU)«. They come in several standard sizes (usually referred to by their thickness): 6 inch, 8 inch, 10 inch, and so on. They have hollow centers to reduce weight, and improve insulation.
wrt wall:structure vs. structure: I think on a barrier=wall we should use structure, but if we describe the wall on an object that is not itself a wall, we would use wall:structure to make clear what the tag refers to.
Regarding the “concrete_block”, I think the replacement (if any) should take into account both parts, “block” and “concrete”. I am not sure, but I think a concrete block can come in different sizes and sometimes also be bigger than a concrete brick, which I would presume to have the same of similar size (like a brick).
Keep in mind that we could always mimic the surface=*-tagging pattern for material=*. Thus, we could use brick:base=limestone/concrete/clay or refine concrete walls further with concrete:density=*, concrete:reinforcement=*, or even concrete:additives=*. Generally, I favor an iterative refinement approach over lots and lots of different values incorporating material and structure.
However, such detailed specifications are beyond the scope of this proposal. I just wanted to show that it’s generally possible.
In the case of concrete blocks, I chose a dedicated value because they are so common worldwide.
While I usually prefer generic interchangeble attributes, it’s mostly considered for ones that are truly shared. Eg material= is the same for the everything. But the structure= for power= and =wall are different. service= , usage= , and substation= are mostly historical, and didn’t consider this aspect fully.
One reason for using material=concrete + *structure=masonry is usability at the same time. If searching for any concrete-made walls, both =concrete and =concrete_block (and any other appearing later) have to be matched by union of equality (or regex), while only =concrete needs to be considered otherwise. Distinguishing different aspects is more organized and easy to handle.
I don’t think it is easier to handle, if there are just wall types, you can get the list from taginfo and know what to expect, e.g. a concrete block wall. If you go with tagging different properties you end up having to handle all kinds of combinations
My original proposal was actually suggesting to use wall:construction, but I changed that, because of the ambiguity this might create. Thus, I settled for structure, which is probably not perfect, but still close enough.
They are different enough that they can be separated. There’s no need to further differentiate them if it uses wall:structure= directly. You are assuming all vals will be documented, supported, and put in presets, by all editing software. This has low extensibility for new val. The input interface would need to be usage-aware and context-aware in suggestions and autocompletes. Not all are such sophisticated.
The structure= in power= is not all “sturctures” proper. Both lattice= and frame= are “frames”, with the latter trying to say “flat frames” (I forgot what would be English term). =h-beam , =trunk , =pipe , =spun , and =cylindrical are all a single vertical member, differing by shape, or how they are made. =wall_mount for =catenary_mast actually means no structure for it.
In my case, the reason why I’ve specifically chosen material=concrete for structure=masonry is that it’s analogous to surface=paving_stones which today are usually made of concrete blocks but also includes clay bricks (though surface=brick also exists) and tiles out of stone (usually indoor).
