Talk:Simple Indoor Tagging

From OpenStreetMap Wiki
Jump to: navigation, search

named levels

I know a funny living house with the entrance labeled with Level 0, below is K (for German Keller), but on top is the level E and then the levels 1,2,3,4. I did not found an approach of labeling levels in this proposal. If we do not use the real names non_existent_levels=* would be not needed. --Zuse (talk) 11:05, 20 September 2014 (UTC)

Ok, read more. Here tagging the Keller as level=-2 and the "0" as level=-1 seems the best approach. And the names added to an indoor=level way. sorry for the noise... --Zuse (talk) 11:23, 20 September 2014 (UTC)
I had the same question. There should be some sort of (OSM) level number to (real world) level name mapping (i.e. connection) to make it easy to verify and find the levels in the building. Example: Real building has -3, -1, K, E, 1, 2, 4. If we set E==0 (K is -1, -1 is -2, -3 is -4) then we have min_level=-4, max_level=4, non_existent_levels=-3;3. But -3 exists in reality, which makes this counter intuitive. At least we need the information what real world level maps to level=0. Or should the OSM level include E and K, i.e. use the same level names as the real object? --holgermappt (talk) 13:07, 20 September 2014 (UTC)
> "at least we need the information what real world level maps to level=0"
you get this connection for free by connection the outdoor world via a footway to the entrance=yes node, which is also door=* in the indoor world. --Andi 20:48, 20 September 2014 (UTC)
But this works only if there is just one level with an entrance and if you are not at Munich Airport where ground level is level=3 and not 0. If you have a complex structure like an airport with airplanes (an doors) at one level, public transport at an other level and cars at a third level then you get confusion for free because you have a lot of footways and doors. The issue I see is that real world level names (which can be numbers) are mapped to level numbers and there are cases where real world level numbers map to different OSM level numbers. People will "correct" the non_existent_levels=-3;3 to non_existent_levels=-2;3 because the real world level -2 doesn't exist and not -3. Level numbers are good for computers, but level names are better for humans. So why not use the level names that are used in the building (in combination with something like level_order=-3,-1,K,E,1,2,4)? This would also help for navigation because with numbers you have to say "go 5 levels up" (because you cannot know how the target level is named) while with level names you can say "go to level 5a" (if the level is labeled 5a in the building). --holgermappt (talk) 21:40, 20 September 2014 (UTC)

level ranges

If a room goes from level -4 to -2, is this written as level=-4--2? Or level=-2--4, level=-4-(-2), level=(-4)-(-2)? Same for repeat_on. --holgermappt (talk) 13:14, 20 September 2014 (UTC)

We discussed this issue beforehand and propose level=-4--2. Yes, this is missing in the examples. --Andi 19:00, 20 September 2014 (UTC)

Advanced modelling the different levels

I think the sketch for the advanced modelling is very confusing. In the proposal it says that the ref-key is used for the ref number of the room, but here it is apparently used for the level ref. You also say "Local level notations per building should be reused", so shouldn't it be level=0,level=1,level=2,level=3 instead? And shouldn't the repeat_on=* correlate with the levels and not with the refs? Don't the entrance and door elements need a level=* tag, too?

Also the caption of the image is wrong in the proposal. --Mapper999 (talk) 14:07, 20 September 2014 (UTC)

You're right. It was a quick sketch and I fixed it now. repeat_on=* now correlates with the level, entrance got a level=*-tag. Regarding the ref-Tag: I tried to abstract the sketch as it contains indoor=xxx. What would you propose to add for better readability? ref=yyy? Or remove ref-Tag at all? --Peda (talk) 16:32, 20 September 2014 (UTC)
I would add the ref tag for levels to the proposal page (could also be letters like "E","G","U1" etc., right?), and maybe change the indoor tag to level in the sketch. I think the ref tag is quite useful here as it shows how a more complex level structure can be mapped.--Mapper999 (talk) 16:59, 20 September 2014 (UTC)
Indoor2.0 buildingpart.svg

I still find the level notation rather confusing:

  • how would you map the elevator ? as an area or as a simple node? you probably need an area to show which doors go to the right and which doors go to the left;
  • how do you indicate, in the elevator object, at which level it stops? If you use the same level value for rooms on the left and rooms on the right (although they actually require separated stops in the elevator because they are at the same physical level), you cannot indicate properly which door connect to the elevator.

That's why I think the level=* tag should be numeric and, whenever necessary, fractional and different from the local level name (which might have another tag, such as level_name=*). For a real-world example, you may see what I tried to do in the Louvre museum, which is full of small stairs and elevators. I can't figure a way to map this and allow for proper rendering and routing without fractional levels. Thbz (talk) 21:55, 3 January 2016 (UTC)

Misc discussions in german


repeat_on=* for office building doors

Tordanik has changed in my addition "or doors to identical stacked rooms in a office building". Please explain how to model with existing tools the four doors at node without getting crazy and without creating nodes with identical position. In my opinion this is the same quality of necessity as for windows (which was you example). Making new ways for each stacked room was no problem (and needed as they have different ref=*, but for the doors this is not true. --Zuse (talk) 13:18, 6 October 2014 (UTC)

The repeat_on tag and similar solutions are problematic for routing (usually, shared nodes are condsidered a walkable connection), but also require special support in all other applications. The reason why this was nevertheless introduced is because some situations cannot be (cleanly) expressed without it. These are the cases where
  • nodes are in the same location, and
  • nodes have to be part of the same way.
If both of these conditions are true, something like repeat_on is necessary (if you don't want to "solve" the problem by placing the nodes a few centimeters apart from each other). This is the case for windows in the same wall, and doors into the same (multi-level) room, as far as I can tell.
However, due to the downsides, this was not indended to be used liberally in cases where it is not necessary. There, copying the level layout and changing the level tags, resulting in nodes with identical lat+lon would indeed be what I would have expected. --Tordanik 11:02, 7 October 2014 (UTC)
Shared nodes can not imply walkable connection without looking at the level tags in the indoor world. All doors in my building shares way of the rooms on all levels which have a wall at this coordinate. Everything other would be a nightmare without massive use of filters in josm at the creation time and are practically not editable afterwards (or you have to use Level0 for it). For example extracting a way from a door one level up. With repeat_on syntax it is quite easy to model and manipulating the building in full detail, perhaps even with editors other than josm.--Zuse (talk) 14:18, 7 October 2014 (UTC)


How would a balcony be mapped in this schema? I suppose there could be an indoor=wall between the inside and the balcony, but then there's no indication that there's an accessible, outdoor area there, other than perhaps a door. Maybe an indoor=area for the balcony? Although the tagging doesn't quite fit (because it's outdoors not indoors) I think it might get the meaning across. Feedback? Other ideas? --Oddityoverseer (talk) 16:55, 29 October 2014 (UTC)

The wall is only needed if the adjacent indoor thing is not indoor=room. indoor=area should be usable for the balcony. But some people tag the building outline without a balcony, which would be a problem here.--Zuse (talk) 07:16, 30 October 2014 (UTC)

Pictorial needed for vertical connections

The page is somewhat unclear on how to map vertical passages. It would be helpful to include a pictorial example of things like stairwells, free-standing stairs, escalators, elevators, ladders, ramps. Maybe others? --Oddityoverseer (talk) 17:04, 29 October 2014 (UTC)

In File:Indoor2.0 buildingpart.svg the tagging of the elevator area is needed. Yes.--Zuse (talk) 07:16, 30 October 2014 (UTC)


It is proposed to use stairs=* to map indoor stairs. However it is unknown what `*` is. Currently stairs=yes is the only meaninful value that is being used ( Should we change the proposal to use stairs=yes? --K1wi (talk) 18:22, 12 October 2015 (UTC)


How do we map escalators? The old IndoorOSM used buildingpart=verticalpassage + buildingpart:verticalpassage=escalator.

Should we use indoor=room + escalator=yes? It is currently deprecated.

Should we use indoor=room + stairs=yes + conveying=yes?

--K1wi (talk) 19:02, 15 October 2015 (UTC)

I think conveying=yes would be the preferred solution. --Tordanik 16:30, 21 October 2015 (UTC)
I added that tagging to the proposal. --K1wi (talk) 18:52, 31 October 2015 (UTC)

repeat_on and level on one object

Someone changed recently the page, adding the statement that repeat_on=* should not include the level=* value. This imply that an object which is repeated through levels should have both level=* and repeat_on=* defined. Is the edit of wiki completely arbitrary or the result of a discussion ? Current support in OpenLevelUp considers only level=* or repeat_on=* for an object, not both at the same time. Is it necessary to change it ? --PanierAvide (talk) 15:52, 9 March 2016 (UTC)

Indoor2.0 buildingpart.svg
Key:repeat_on is not perfectly clear. But in the image on the right, repeat_on=* clearly replaces level=*. If I were you, I would recognize both... Thbz (talk) 17:28, 20 October 2016 (UTC)


The various ways in which to specify multi-level features, e.g. "1;2;3" or "1-3" could be difficult to query for, e.g. in overpass. Any thoughts? Bjohas (talk) 17:58, 2 July 2016 (UTC)

Do you have an example what you are trying to find? RicoZ (talk) 11:37, 3 July 2016 (UTC)
For example, see here I've tagged all objects using separate levels, "-3;-2;-1". So the above could be retrieved with way["level"~"\-1"]. However, if the object was tagged "-3-0", and I wanted to extract level=-1? I can't easily use a regexp, because the tag could be "-4-0", "-5-0", etc. One could use "\-[9876543]\-[01234]" but that only catches certain floor, and would get more complex with fractional levels and variation in spelling. Ideally one would want a filter (levelbetween:A;B), where A and B are the start/end level, and (levelaround:A) / (levelaround:A,Z) where Z is the vertical area to look, e.g. 0.5, 1, etc.
This is probably as good as you can get now - you can write eg [9876543] as [3-9] instead but that won't solve the other issues. There is going into a similar direction but it might be worth opening a new ticket for number (and perhaps date) range comparisons. RicoZ (talk) 16:09, 6 July 2016 (UTC)

highway=footway/steps inside buildings

Is highway=footway/steps forbidden inside buildings?

OpenLevelUp displays them as expected (when level=* is set correctly, of course). The alternative is to map every corridor or stairs as an area (closed way), which is rather inconvenient in many cases (e.g narrow corridors, train stations, etc.), where you mostly want to show which way people can use to go from one place to another. Thbz (talk) 07:47, 20 October 2016 (UTC)

I notice that OpenStationMap recommends using highway=footway/steps, which is necessary for routing. When using an area for stairs, it is impossible to know which is their direction. Thbz (talk) 17:23, 20 October 2016 (UTC)

Direction of conveyors

I like the proposal, but I think, that it did not get the stairs right. I have several arguments, but to simplify I wonder how you solve the most simple question which is direction in which escalator moves. Obviously, this is absolutely crucial for navigation and it seems to me that it is currently impossible to do so, if you mark stairs as an area. Even the examples which support the chame does NOT follow it in this particular case and they use good old fashioned way. BTW the german station example gets it right I guess. They mark the area and they put the highway=steps way in the middle. I thing the proposal needs to change to mimic this. --Gorn (talk) 21:42, 12 March 2017 (UTC)

Yes. With escalators I always put a highway=steps way. The area may be added too but it's clearly less important. Even with stairs, as I said above, an area might be confusing in some cases.
One problem is that the standard renderer at renders highway=steps paths, even when they are tagged as indoor=yes, which is not desirable since only outdoor elements should be rendered by default. But of course we do not map for the renderer... Thbz (talk) 04:57, 13 March 2017 (UTC)

Solution to repeat_on=* for doors

In the spirit of "progressive mapping" I have a suggestion for repeat_on=* tag. The repeat_on=* tag seems ugly and theoretically incorrect, but it is very simple an practical. It is a hack around the fact, that OSM model does not allow multiple nodes on same position (but it allows multiple ways). However it fails for example in case that doors on different levels have different properties (i.e. some are sliding and some are not etc) and in many other case. I therefore suggest:

  • Keep the repeat_on=* for simple cases and as a step in "progressive mapping" style when you want to make the door fast and simple.
  • If you want to map into more detail, that let us allow door=yes (and related tags) to be applied to a *way*! Most of the time it would be simple two-node way.

In case you do not see geniality of the proposal for yourself ;-), here are several problems it solves immediatelly

  • You can have more doors on the "same place" each with different level=* tag and properties.
  • the tags like repeat_on=-3;-2;-1 are not needed, just a simple level=-2 etc.
  • The width of the door and the placement is contained in geometry, no additional tags are needed.
  • It even solves the complicated problem of direction of opening (see F3DB#Tagging_of_door_direction), because the way has orientation. Detials needs to be proposed, but it is obviously easy.
  • If you want you can also easily mark placement of hinges (which might be interesting to wheelchair users and/or architects).
  • If ingeniously solves the current hack door=no which needs to be used when there is no barrier between corridor and stairs etc. You just make the door as wide as the whole edge or touching areas.

What do you think about this --Gorn (talk) 22:46, 12 March 2017 (UTC)

The idea of using a way is very interesting. But how does it solve the door=no hack? What tags would you use in such a situation? And something is missing in this tagging scheme: the entrance=* tag. It seems that door=no is not necessary if you specify this is an entrance (which I do on nodes, but might do on ways according to your proposal). Thbz (talk) 13:04, 10 April 2017 (UTC)
I would also like some clarification how this impacts the use of door=no, I believe didn't fully understand that point. Regardless, this is definitely a clever suggestion, and I agree that there are good of reasons why we should allow doors to be mapped as ways. --Tordanik 23:46, 11 April 2017 (UTC)

"Local level notations per building should be reused" in praxis

I wonder what exactly this advise means. In big (partly undeground) shopping malls the level numbering may not be aligned with the outside world. To give an example this shopping mall names ground floor "3rd level", first floor "4th level", -1th floor "2 floor" etc. Now the question is if

  • use level=2 for what they call the second floor (although it is 1st undeground floor in reality)
  • or to use level=-1 and put level:ref=2 on the outline of level, as suggested here.

First approach is does follow the advise "Local level notations per building should be reused" quite strictly, but level=* values will not match reality + more importantly the will not match the surrounding - there is a corridor to metro station which uses the levels differently (in fact it respects reality more).

Second option is more complicated, but perhaps correct.

Please advise.--Gorn (talk) 10:10, 10 April 2017 (UTC)

In my opinion, the problem is not the connection with the outside world (which has no levels, only layer=*s), but when connecting with another indoor area that follows another level numbering scheme (the metro in your example). I try to use the local level notation whenever possible, even if it looks weird (I did it at the Roissy Airport Terminal 1 recently), but I use my own scheme when there is any problem with the local scheme (for example, at the Louvre museum, which level numbering scheme is too simplistic and could not be used for routing). Something like level:ref=* for the official level is interesting. Thbz (talk) 13:13, 10 April 2017 (UTC)
Yes there is a problem, that there are two multilevel structures connecting (metro station and shopping mall) with different levels. The problem with the first approach is that it may confuse the router - there is a highway and/or corridor area coming from one side marked level=-1 which continues in level=2 on the other side. And I wonder how to tag the connecting door - if I add both of levels it may look more like an eleveator connecting two different floors. --Gorn (talk) 16:23, 13 April 2017 (UTC)

indoor=room and indoor=area sharing edge

Is there a wall when indoor=room and indoor=area share the same edge? From practical point of view there should be one. --Gorn (talk) 11:14, 10 April 2017 (UTC)

Since a indoor=room is defined as a conventional room with walls, it seems obvious to me that there should be a wall there. Thbz (talk) 13:17, 10 April 2017 (UTC)