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)