Talk:Simple Indoor Tagging

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)

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

see http://forum.openstreetmap.org/viewtopic.php?id=27065

repeat_on=* for office building doors

Tordanik has changed in https://wiki.openstreetmap.org/w/index.php?title=Simple_Indoor_Tagging&diff=1092549&oldid=1091932&rcid=&curid=129411 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 http://www.openstreetmap.org/node/3103804203 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)

Balcony

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)

How would one map indoor balconies? For example, a large room has a balcony that surrounds the entire circumference of the room. This would call for a multipolygon with the inside part that has no area and only leads to the ground floor being the inner area and the balcony floor outline or a indoor=area as the outer. Is this correct? Should I add this usage of multipolygons to the article if correct? --Lectrician1 (talk) 04:51, 1 March 2021 (UTC)

indoor balcony example

An indoor=area tag on a multipolygon is how I would map it. That is:

• Balcony area (relation)
  • type=multipolygon
  • indoor=area
  • level=1
• Room area (closed way)
  • indoor=room
  • level=0-1

The image is how I understood the situation. (I couldn't resist also adding some decorations like windows and a railing. :)) --Tordanik 22:23, 1 March 2021 (UTC)

Not sure if it needs to be added, to me it logically follows from what's documented? Multipolygons don't have any different semantics compared to other areas. If the balcony didn't wrap all the way around, you'd just use a "normal" area instead. --Tordanik 22:23, 1 March 2021 (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)

stairs=*

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 (http://taginfo.openstreetmap.org/keys/?key=stairs#values). Should we change the proposal to use stairs=yes? --K1wi (talk) 18:22, 12 October 2015 (UTC)

thought it was related

https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dsteps

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps --Masaki123(talk) 19 January 2018

Escalator

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)

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)

Multi-level

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 http://openlevelup.net/?lat=51.530411&lon=-0.124583&z=18&t=0&lvl=-2&tcd=1&urd=0&bdg=0&pic=0&nte=0&ilv=0. 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 https://github.com/drolbr/Overpass-API/issues/78 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 openstreetmap.org 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 http://www.atrium-flora.cz/obchody/ 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)

Proposal: Adapting this to work with "Simple 3D buildings"

The article should explain how this can be combined with Simple_3D_Buildings. Do we drop min_level and max_level? or do we use them in combination with the tags in Simple_3D_Buildings, and so on. -- SwiftFast (talk) 07:53, 14 May 2017 (UTC)

Regarding levels specifically: Using the tags combined makes sense. Each schema captures something different: The tags in Simple_3D_Buildings capture the external look of the building and do not care at all about the numbering scheme, whilst min_level, max_level, and non_existent_levels are all about the numbering scheme. -- SwiftFast (talk) 08:15, 14 May 2017 (UTC)

Compatibility with Simple 3D Buidlings is an explicit goal of Simple Indoor Tagging, so if you notice any incompatibilities, please point them out. When combining SIT with S3DB, tags from both should be used at the same time. This allows for the level numbering to be different (S3DB has a pretty clear definition of level 0, which may not be what you want for indoor level numbering) while still allowing programs to match up the "indoor levels" with the 3D "outdoor levels", so a seamless outdoor and indoor model of a building can be calculated. --Tordanik 13:08, 14 May 2017 (UTC)

Thanks for the clarification. -- SwiftFast (talk) 14:39, 14 May 2017 (UTC)

@Tordanik: I like the way you explained it. Is it alright if I add your explanation in a summarized fashion to the page? --IanVG (talk) 21:12, 3 August 2021 (UTC)

@IanVG: Works for me, go ahead! I can always tweak the wording or placement afterwards if I see any room for improvement. --Tordanik 15:41, 7 August 2021 (UTC)

Mapping things that are on top of the roof

Suppose there's an amenity, (e.g. a cafe, a helipad, a swimming pool) on top of the roof. How does one tag it? My common sense says I should use the level=topmost level + 1, but this is not mentioned explicitly anywhere in the page. In my particular case, there are external doorsteps that reach the top of a roof. -- SwiftFast (talk) 14:39, 14 May 2017 (UTC)

Also interested in the answer, and also (very similar) how to map various kinds of terraces. RicoZ (talk) 12:45, 15 August 2017 (UTC)

stairs tagging : new section

thought it was related

https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dsteps

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps

There seems to be two different tags using stairs and steps being proposed as an area. i have seen stairs already being implemented. Are either of these currently acceptable?

--Masaki123(talk) 19 January 2018

The Area-steps is interesting, as it might help to indicate the steps direction and even the conveying direction. I still have problems with the Simple Tagging stairs which cannot give this information. Thbz (talk) 11:24, 22 July 2018 (UTC)

Show Buildings in Common Viewer : new section

Are there any plans to show the indoor tagging in common OSM viewers like https://www.openstreetmap.org/ and OSMAnd?

You would probably have to ask the developers of these viewers for reliable info. But at least for osm.org, I'm not aware of any plans. Unfortunately, the openstreetmap-carto map style is still rendered entirely on the server side, which makes it harder (although not strictly impossible) to allow level selection in the user's browser. For OSMAnd, you can read a bit about the current status here. --Tordanik 17:21, 23 April 2018 (UTC)

Hospitals indoor mapping

I need to map the interior of some hospitals. The problem is that the simple indoor tagging has not a way to tag an "area" containing areas, rooms, corridors etc sharing the same "use" (or medical speciality in this case). For example in my hospital the emergency department has 15 rooms, 2 parallel corridors (that permit to reach and pass through the diagnostic department) and a big waiting area...I can map every single element but not the emergency department as a whole.--Aury88 (talk) 16:04, 22 January 2019 (UTC)

My suggestion would be: Draw an area encompassing all the rooms, corridors etc., and add the tags for a hospital department to it, plus an appropriate level=* tag. If that doesn't work, you can use a relation instead of an area.

But what "the tags for a hospital department" in the above statement should be – I have no idea about that, and I feel it's beyond the scope of indoor mapping. Instead, that's a question which mappers who know more about healthcare need to discuss. --Tordanik 23:07, 21 January 2019 (UTC)

Here obviously I'm referring about the indoor tagging. I hoped there was a specific value for indoor=* to map an indoor "sector"or department of the building (something that can be found in others types of buildings other than hospitals). The tags for the hospital's departments will be discussed in a dedicate ML or other tag's talk.

PS as you can see I never talk about "the tags for a hospital department" but about how to "tag an "area" containing areas, rooms, corridors etc sharing the same "use"", the hospital is only an example of element containing sectors that contain rooms, areas and corridors--Aury88 (talk) 16:04, 22 January 2019 (UTC)

From my point of view, the indoor=* values are purely about the physical layout of the floors, though, not about their use. This is a parallel to how building=* is about the building as a physical object, with the use being mapped using tags such as amenity=* or shop=*. Once you've drawn an area that carries "the tags for a hospital department", why is there a need for any further tags? Sorry if I misunderstand your goals. --Tordanik 19:02, 2 February 2019 (UTC)

Shop spans multiple levels and the area differs

How to tag a shop that spans multiple levels when it doesn't occupy the same are on all levels? The physical part (indoor=room) is clear. But what about the shop itself? Should it be a multipolygon of all rooms, a polygon covering the union of all footprints, ...? Illustration feel free to upload it here--Shoepuppet (talk) 09:22, 1 July 2019 (UTC)

Mapping such a shop requires multiple areas, each with its own level tag, that are member of a relation. This relation cannot be a multipolygon because it would break the normal multipolygon rules (e.g. no overlapping polygons) that software working with OSM data relies on. The most suitable existing relation type is probably  site. --Tordanik 18:09, 9 July 2019 (UTC)

If this is the "official" opinion I think somebody should add it to the main article. Took me ages to find it here --Mfbehrens99 (talk) 16:10, 26 April 2022 (UTC)

Sharing Nodes with Building

How should I approach the connection of nodes between indoor=room and the surrounding building outlines? Has anyone seen this gif of someone doing some indoor mapping? https://wiki.openstreetmap.org/w/images/0/03/Indoorhelper_how_to.gif IanVG (talk) 14:00, 17 April 2022 (UTC)