Hi,
I would like to gather a bit of feedback before I do a proper change proposal.
In the forum posts that I have read, allowing area=yes for indoor=wall seems to not have found big opposition.
In our local area, this gets reverted, as it is not part of the simple indoor tagging spec.
I am new to the spec-game, would a proposal to allow area=yes for indoor=wall find baseline acceptance?
The current tagging that I can find with overpass turbo is varying. Given the level of existing tagging, just allowing closed ways would require non-trivial amount of work.
What’s the intended meaning of area=yes with indoor=wall? If it’s an area, wouldn’t that usually be tagged as indoor=room, where the walls are already implied? Just trying to understand the rationale.
Valid data is valid data and I’m a big fan of micromapping, but I suggest you use different tags (not indoor=wall+area=yes) rather than muddying the meaning of indoor=wall, which has been defined as applicable to ways only. Something like area:indoor=wall? The outcome of indoor=wall+area=yes is that consumers will inevitably end up treating the objects as closed ways anyway, not as areas as you intend - similar to highway=*+area=yes vs area:highway=* and the barrier=*+area=yes issues like barrier=hedge or barrier=retaining_wall.
In previous discussions, there was definitely appetite for allowing this.
Do you plan to include a suggestion on handling doors in the context of wall polygons? The usual approach of having a node shared between the wall way and the two adjacent room polygons doesn’t easily work in that situation, after all. Do we map them as ways? Or do we just prohibit placing doors into walls mapped as areas?
As a data consumer, I would prefer indoor=wall being extended to areas. It’s the same conceptual feature, just mapped as a polygon instead of a line. Using area:indoor=wall has all sorts of weird implications, such as being mapped in addition to a way like with area:highway=* (which is undesirable).
My impression is that the indoor space doesn’t suffer as much from unmaintained or hyper-conservative renderers which would fail to update for years. And if some do end up treating the object as a closed way instead of filling it in, that doesn’t really break much.
I don’t see doors as controversial in this context. Maybe I am missing something.
They are currently modelled like this (omitting plenty of tags relating to how the door works):
Since that how I know OSM, the latter sounds controversial, I’d like to hedge the bets and split this into two proposals, one after another. Doors with directions only really make sense if you have walls with thickness.
I don’t quite sync with you here. There seems to be some implicit thoughts.
Why would consumers ignore the area=yes tag?
If they do, they now have more walls inside their walls.
Renders a bit weird (first image), but still works.
If renders support the area=yes tag, great! That gets rendered as a thick wall.
Is the wall recessed even above the door? If not, your mapping is a bit of a simplification in that regard.
But that’s probably something I only notice because my main use case is 3D rendering. It’s reasonable enough to map the extent of the rooms and walls at floor height even if it will look wrong in 3D.
+1, what is missing is the position of the door in the wall, you depicted a centered version but much more often doors are on one side of the wall. How can we express this with tags, or shouldn’t we and it should better be done geometrically (way position in the area wall)?
the blue line (wall) would be mapped as a rectangle with a height, and the opening inside as another rectangle with its own height, the position of the door decides which room owns the space of the opening, unless there are 2 doors and it is in its own right.
The door could be an additional way, the node where it is attached could get a hinge tag (if it is a typical door, not to be used for sliding doors)
Seems like a somewhat confusing to tag and relatively breaking change.
We have already established that the level of brekage this would introduce is not such a huge issue, the confusingness more.
I would completely discourage this approach, it is an abstraction that leads to unnecessary fragmentation and indirect mapping which is not how we “naturally” perceive things. Imagine a wall with many openings, some of which could be partially overlapping but not completely (horizontally, i.e. when projected to the ground), the result would be an utter mess of wall fragments at different heights.
With the alternative approach (single wall object, one object for every opening), we’d have a much better representation, respecting how we would naturally describe the situation (a wall with openings, rather than several walls with different heights and starting heights).
Imagine a wall with 10 openings and you later find out it is mapped 5cm too low, with my approach you would only adjust the one wall, with the other approach you would have to adjust 12 “walls” (which are all together one actual wall). If you wanted to add detail about the wall, with your approach you would have to repeat the wall tags for every fragment, despite it is just one wall. It doesn’t scale well and isn’t intuitive, hence error prone.
Also if you wanted to map further details of the opening, with the serial-wall-fragments-approach you won’t have an object to add the detail to, e.g. that the sides are wood clad, or that the corners are bevelled or something like this.
Remember this is not just doors (which would already be sufficient) but also windows. If we haven’t yet (I do not follow closely the indoor tagging evolution) we should definitely introduce an “opening” element so we can map doors and windows naturally instead of having to puzzle them together indirectly with wall parts.
Sorry, I don’t fully follow your counter-proposal.
I like that we are now in agreement that your min_height above door tagging is confusing and should not be done.
Could you draw a quick tagging-diagram for the rest? I don’t quite understand how that should be done
The proposal makes sense IMO. In reality, walls have a width and having the option to map them as areas would allow for way more detailed and accurate mapping.
I don’t expect that wall areas will replace the current tagging as you often don’t know the dimensions of a building that well that you can tell the width of a wall. But for cases where you do have really accurate data it would be really handy to have a standardized tagging for wall areas.
I modified your drawing, the wall is just 2 lines, but actually it would be a rectangle (outside the view, as in your drawing).
All lines are meeting in the same points, I just offset them for visualization.
The opening would be modeled as a rectangle (green) with a height (and min_height if not 0).
Heights are refering to the current level (relative heights, not absolute heights referring to the terrain).
The door is a line and not a node. It could also have height information if desired (especially useful if it doesn’t cover the full height).
The position of the door in the opening is indicated by the way position.
The direction the door opens has to be given (optionally) via a tag.
The node tagged hinge is optional but useful as a method to define the pivot of the door
Agree, except the opening should not be part of the indoor=room, I think?
To map (outdoor) pathways through buildings, there is already the precendent of using tunnel=building_passage, so I’d think that a similar approach could be chosen here.
could be or not, it shouldn’t probably with 2 doors (one at each room), but with one door, the space arguably could belong a room (or even both, if it was in the middle).
As a data consumer, we can render indoor=wall+area=yes already anyway, and as long as there’s no doors in them our router will see this as an unreachable space and thus also do the right thing already.
The main argument against thick walls in the past was it interferes with “rendering” tactile maps, as controlling the wall line width is quite important for this. But for complex walls like in your example that cannot reasonably be represented as a “clean” thin line I don’t really see a good alternative. We probably should stick to thin walls whenever that’s reasonably possible though.
