“shrinking walls” (buffer without overlap) is something that can be done for the tactile maps people. It falls apart quickly when walls are “lumpy”, but for too thick walls you likely don’t want to squish either way, not sure what the cartographic needs are there.
I consider this a fairly specific use case and would not optimise tagging data explicitely for this 
To maybe try to sum the discussion to this point up, I don’t think this is something where we can make both camps entirely happy.
non-controversial:
- that more detailed data is nice.
indoor=dooras ways might make more sense under this tagging, but nodes also work
indoor=opening |
no indoor=opening |
|
|---|---|---|
| 3d indoor rendering | needs work, but less | needs work (f.ex. tagging on the doors) or can be inferred |
| 2d indoor rendering | needs changes | backwards compatible |
| navigation | needs work (no walking through walls) | good |
| craft-tagging | more work | less work |
| imports | good | good, little more work (splitting openings, adding them to rooms) |
To maybe try to gain a bit of insigt which way the community is swinging:
indoor=opening- no
indoor=opening - lets discuss this further
- abstain
0
voters
actually I do not believe the no-indoor-opening tagging needs less mapping work, the drawing is yet incomplete because you would also have to draw the wall above the door. What would be eyeopening I think is an example of a wall with several openings on different heights which horizontally overlap, mapped in both variants.
One caveat about that image: Thin walls should be drawn through the center of the wall, whereas thick walls should be drawn at the edge. So the thin wall/door in your example should still be inset a little.
(By the way, I think any proposal should explicitly mention this distinction about thick walls being drawn along the edge of the wall.)
I’m not a fan of the mix of “additive” (indoor=wall) and “subtractive” (indoor=opening) mapping, that is rather complex to handle for both renderers and routers (needs e.g. processing elements in the right order). If we want that level of detail, I’d rather suggest to map the parts over the doors additive as well (e.g. indoor=wall, area=yes, min_height=2).
what I meant were situations with more than one opening, which might even not align vertically, e.g. like here to the left
if you puzzle it from wall stubs on different heights rather than having a single wall and defining openings, it will get awkward or at least unwieldy
For this example I would need 7 primitives in my modeling (1 wall and 6 openings: 4 windows and 2 doors, all of which would be clearly described with their actual measurements), opposed to the stacked walls method, which would need at least something like 12 wall parts (if I counted correctly, and depending how you slice the wall), and would be quite hard to verify by just looking at the modeled data, because there wouldn’t be a direct relationship like opening measurements in the data, it would all be indirect, and error prone.
18 at most. Depends a bit on the alignment of the windows with the through-counters/lower windows.
I can’t get it lower than 15, but that kinda shows the point.
Edit: Got it down to 12. I’m sure there is an interesting algorithm to determine the most efficient layout. Though not necessarily what we want in OSM.
1 Like
how about this (right version):
- doors always have an implied wall above if you are rendering 3D (which is likely to be the common case, we are indoors)
- openings are only “non-walkable” openings
- openings can be replaced with windows to not have to tag this twice, if there is a glass
This way, we optimise for what I consider the average case:
regular doors, regular walls, no overlapping openings at multiple levels
You (3D people) would then still have to do the boolean arithmetic, but it would be much simpler for navigation, 2D rendering
My focus is on simplicity and comprehensiveness. To represent a wall, I would not want to draw 2 walls instead of one, just because it happens to have a door, and I would not want to have “implied walls” above doors, because it adds complexity that is not naturally intuitive.
To the normal person, a wall with openings is a wall with openings, the tesselation should be done by software, not by the mappers.
If you do not like the generic approach with “opening”, it could also be differentiated at the top level in “door”, “window”, “opening” (i.e. open), maybe also something for technical pass throughs, hatches, etc.
From a 3D rendering perspective:
For windows or other non-walkable openings, I’d be happy with a node – either placed on one of the polygon’s edges (that’s the option I’d use if the wall is an outer wall of the building, where I would want the window node to be part of the building=* way), or floating in the center of the thick wall.
I expect drawing the window as a polygon as in your image wouldn’t really make my job easier. Window shapes are generally described as 2D shapes (“rectangle”, “circle” etc.), so for any non-rectangular window, I need to figure out the two wall faces into which to place these 2D shapes. That should be possible just by using the closest opposing wall faces from the node.
So for everything except doors, I think the recent suggestions are overkill. Nodes do the job well enough.
Doors are more complex because they need to work for navigation, and as @VolkerKrause mentioned, the “floating nodes” approach would be challenging for that use case. Looking at it strictly from a 3D point of view, I believe good results could be achieved with either a “floating node”, or a door way through the thick wall.
Looking at this I see a room wich consists of two diffrent levels. As soon as this room is adjacent to a another room/building on any side, you have to model this room as going over two levels to not have a height missmatch.
This problem becomes even more obvious if the gymnasium has a walkway on level 1 or you can look through the windows on level 1 down into the hall which is on level 0.
Because of this horizontal cut the walls wouldn’t be that much cut into pieces.
“floating nodes” inside of the wall is not acceptable for 2D or tagging.
Way too complex and non-intutive in both cases and not supported by any of the tooling.
I don’t think we should go this way
I see just one level in the room, it is high enough there could be two levels and people could still stand, but it wouldn’t be useful for basketball anymore.
Thinking 1 level = 3m is ok as an approximation if no indication is given, but generally even in the simple model we should be able to capture different floor heights, split level, inserted levels and stuff like this. The non-simple model would cover inclined or curved floors ;-)
What confuses me about the continuous walls:
Things like barrier=wall or barrier=fence all semantically represent a barrier.
At least until now I thought that indoor=wall also represent a barrier, at least something impassable.
But if a barrier has a min height of 2 it is passable again. This means that there is implied information that this barrier is, infact not a barrier. Something like indoor=overdoor wouldn’t make this confusion.
Tagging those overdoors as a wall or making walls continuous scream tagging for the renderer to me. This seems to complicate quite a bit semantically and for 2d rendering to make it slightly easier for 3d rendering.
Well this is just a big scope creep regarding this discussion.
This is about how to change Simple Indoor Tagging a bit without breaking much with current renderers, processing and not developing a whole new Advanced Indoor Tagging scheme.
To be honest I would propose to not further discuss Openings or Windows in this discussion. This seem like a more Advanced (pun intended) topic for a diffrent discussion topic.
While I am quite Interested in discussing more complex Schemes I think that going smaller steps will help more in bringing indoorosm forward.
if the question is mapping walls as rectangles instead of lines, the question of openings is implicit.
I am not sure how indoor=openings enable inclined or curved floors or which of the two the non-simple model is that you mean that covers this and how? 
I don’t think non-planar topology is possible in OSM, but I would be happy to be proven wrong.
Here is the updated drawing with only one floor and the windows as points:
