Proposal talk:Allow area=yes for indoor=wall

Doubt about the necessity of area=yes for indoor=wall

The problem statement is clear: for thicker walls (e.g. 50+ cm) allowing only simplified representations as single lines along imaginary axes is admittedly a harsh restriction on mapping detail, could also complicate mapping for certain situations and hinder some use cases.

However, it does not seem necessary to introduce wall areas (allow area=yes) to solve this problem. It would be sufficient to allow the two surfaces of a wall to be mapped with a distance. These two wall surfaces may face two different rooms or the same room. The mapping would then pertain to the rooms, observable (vertical) surfaces as barriers and walkable areas, whereas the (horizontal) area representing the occupied volume of the walls would be treated as unmapped territory. I believe this would more realistically reflect the mapping intention since in common indoor mapping I would not know and care about the internal construction, inner material of building elements or potential cavities. I'd rather map what is approachable and visible to the outside. It would also better match the purpose of the data collection since use cases don't require details of internal construction information.

The proposal contains some additional arguments for representing walls as areas, which I don't find strong and convincing.

• Filling walls with solid color: This idea probably comes from architecture floor plans which are by convention sectional views with a horizontal section plane in 1 m height above floor level. In these plans, fill colors or patterns show material and construction of building elements' sectional areas for the purpose of erection, maintainance or renovation. I don't think there is intention and capacity to replicate this type of construction drawings in OSM mapping. The current rendering with the building footprint color as backdrop to rooms and walkable areas seems perfectly fine to me.
• Consistency with columns: Columns are effectively non-walkable areas within otherwise walkable areas. This is not the case for indoor walls. Thus area representation of these walls is not necessary, assuming that the overall building area is non-walkable except for the enclosed walkable areas, rooms and corridors.
• Distinguish from closed way (with indoor=wall and without area=yes): Wouldn't that be a room effectively, by definition of a room as area enclosed by walls?

Few more counter arguments:

• With area=yes, most indoor=wall features would have to be subdivided into parts where walls touch each other, e.g. situations where walls meet in a T- or X-shaped situation. These subdivisions will be positioned arbitrarily and convey no relevant and reliable information, thus clutter the database and rendering.
• Outer material layers of walls often differ between the two surfaces and are not unique across the wall volume. Thus it might make sense to not treat them as one, but as two elements.

I think the preceding discussion and this proposal provides a good base for a change where thick walls are allowed without area=yes and instead are conceptually treated as two surfaces. I believe this would align well with the current mapping scheme for walls, re-thinking thin walls as a special case with their two surfaces collapsed.