Towards a unified and simple indoor mapping scheme

At SOTM-EU this month there was clearly renewed interest in moving forward with OSM indoor mapping.

See for example the talk by Thomas Graichen

As we all know stuff gets mapped in OSM when there is this positive feedback mapping → visualisation → usefulness, requiring editor and render support and support in applications. All this tends to only happen when a reasonably stable tagging schema exists, best example the simple 3d mapping tagging.

Of all the indoor proposals that exists only seems to have more or less proven itself a bit, and seems to be the best choice for ironing out some of the problems.

IMHO the list of items that need to be addressed is -very- short

  1. fix potential confusion and conflicts with the 3d tagging scheme:

    • replace the use of “buildingpart” as a role and key with, for example, “indoor” or “indoorelement” (applications should support buildingpart for backwards compatibility)

    • replace the use of “building:levels” with “indoor:levels” or similar (conflicting definition)

    • the same for “building:min_level” and “building:max_level”

    • all further 3d and non-indoor tags should be removed from the proposal

    • note: I believe both the 3d tagging and indoor should be able to share the same building relation and we do not need to define something separate

[/*] [*]replace the current (broken from a data model pov) scheme for vertical passages with a relation based one[/*] [*]most important: define support for a simple "POI only" tagging that should be supported, this could be as simple as supporting level tags on the POI nodes. For this to work reasonably well I expect that a minimum set of indoor tags would have to be present on the building relation or building polygon[/*]

I’ve started a straw man for a tagging proposal here


Thank you for bringing up this unresolved topic! I’ve been watching the topic of indoor mapping for years, but the current lack of a consistent way of tagging makes it less attractive for both mappers and developers than it should be. And you have already addressed the most critical obstacles in your post.

However, to emulate the success of Simple3DBuildings, I believe that the tagging schema would also have to be simple. This was an important goal at the meeting where we laid the foundations of 3D tagging, and to me, this means use relations as little as possible. For 3D tagging, at most one relation per building is being used, and even that is optional in practice. All the big renderers have no problems with relation-less buildings and most 3D mappers don’t use the relation.

When I look at the IndoorOSM proposal, I get the impression that simplicity was not a design goal. The most obvious example is the use of OSM IDs in values which you have highlighted already. However, there is some other factor that makes things unnecessarily complex (as already pointed out when IndoorOSM was originally proposed): The relations are not really necessary in most cases.

  • The tags describing the entire building can - and should, for backwards compatibility - be on the building outline.

  • Whether an element is within the building would almost always be clear from being contained within the building outline.

  • What level a feature is on could be defined by a level tag, rather than the membership in a level relation.

So I’m strongly in favour of making the relations optional. With this convention, the “POI only” tagging with level tags on the POI would not be a special case, but simply a normal application of the tagging scheme.

Hello Simon,
interesting suggestions!

We met with Thomas next days to discuss details.
I´m also in the indoor advisory board
The reason for is to build ways between EU Specifications and OSM thinking.

Unfortunately I could not come to the SOTM.
I wolud say, let´s start a specification workshop,
as I started some time before for S3DB in Garching.

Regarding the proposal, thanks for putting it up, I have been mapping using something similar to the IndoorOSM proposal, but adjusting it where I needed to.

Some changes that I have been using:

Ignore the ground_level restriction. I tried doing this initially, but when mapping a building with 4 levels, each of which has entrances from outside (at that level), and for which the main entrance is on the top level, I could not see any benefit with this restriction.

Make the entrances/exits members of the relevant level relation, not the building relation. This includes the level information for the entrance/exit, whereas having it being a member of the building relation does not.

Currently for mapping the lifts/stairs I have been using a area (circular way), tagged with buildingpart:verticalpassage. To represent which levels this allows access to, it is included as a member of the associated level relation. Note that so far I have just been using this data for display purposes, and currently it is not expressive enough to say that, for example, there is a lift shaft here, but the lift does not stop on level 3. The role on the level relation could be possibly used in cases like this?

Some issues that I have encountered:

Could a way be used to represent an entrance to a building which has a width? This would be useful where you have two buildings that join, connected with a large (in width) corridor/space. Putting a node somewhere in the middle of the divide seems a bit broken.

Mapping an outdoor area on the roof of a building is a bit undefined. You could put the bits in the relevant level relation, but by also including the shell, you would be able to determine what bits are outdoors.

What is the intention behind shells for levels? I have not really found a use for them yet. If the building level has a hole in the middle, should the shell be no different, or should a multipolygon relation be used instead?

Obviously if the proposal can be made simpler I’m the first one to support that.

Obviously explicitly tagging the level on all objects could at least replace the level relations, the original proposal however did have tags that were level specific and that facilitiy would be lost if there is no level level :slight_smile: object that they can be attached to. As to tagging the attributes on the building outline instead of on the realtion, no objection to that.


I suspect this to date back to the days before the Simple3D tagging existed and was a different approach to what now is solved with building:part , in other words can likely be dropped. I suspect however that that does imply that you will always need at least one indoor room or corridor object filling out the available space at the level in question or else you would need to reconstruct the geometry from the the building outline and potential building:part polygons at that level (which is likely going to be a bit of a pain).

Hole in the middle is an interesting case, I can see a handful of ways of resolving that without resorting to MPs, but they need some more thought.


PS: while I have some interest in the subject, I’m not in any way an expert /me points in the direction of Tordanik and Marek

We could add the tags to the level’s shell, though, assuming we decide to keep the shells.

It is true that there would be some duplication between level shells and 3D building parts, which is of course undesirable.

However, the proposal currently includes tagging windows, which (according to the example buildings) would be nodes in the shell. This is something that cannot as easily be done with building parts spanning multiple levels: Doing so would mean inserting nodes for windows from different levels, which might be directly on top of each other, into the same way.

Of course we could find a different solution for window mapping. But as the proposal stands, the shells still have a purpose.

I don’t really see a reason why windows couldn’t simply be tagged on the polygons of the indoor rooms etc (and since we are being fairly complete here :slight_smile: there are rooms which have windows inside). I suppose tagging them on the shell would make it easier for a 3d renderer that otherwise is not concerned with indoor rendering to display them.

Using relations makes it easy for the data consumer to enumerate all relevant objects that belong to one building at the expense of making it somewhat more difficult for the mapper.

I think the question we need to ask is: is there enough advantages to the simplification for the indoor use cases by having at least the building relation to make it mandatory?

I don’t really see a use for the level relation (outside of what has already been said). Once you have all elements for the building you can easily recreate any necessary data structures via the level tag. If we make the relation(s) optional we in any case should not allow “mixed” tagging, otherwise we could just as well do away with the relations completly as there is no advantage to data consumers.

I suspect the more interesting question however are the vertical passages. The current proposal “works” (as in Heidelberg had a working routing implementation) but obviously is broken from an OSM data model pov. A non-relation based way of mapping them may however end up being very hackish. My naive thinking is that it should not be all too difficult to create an edge for routing purposes from a relation containing the exits of an elevator. Given that doing this would be slightly “advanced” mapping I don’t quite see the argument against relations here.


This is precisely what “we don’t map for the renderer” (proxy for data consumer) and “Relations are not categories” are about.

I agree that for most developers working with pointers is quite familiar, but working with geographic notions is unfamiliar. But then we are a spatial database and should therefore should people encourage to use spatial relationships.

We don’t have a relation for each city that contains all roads, or even worse, a full hierarchy from city to suburb to neighbourhood to street to street section, and that’s because this would signicantly bloat the database. As buildings exist in similar numbers than streets, the same problem would arrive here sooner or later.

No, there aren’t. It’s just a typical fallacy that people are trapped in that have the best intent but haven’t tried out what scales to planet dimensions and what not.

On the other hand, for mappers again tags are easier than relations, because a feature has a definite property (it cannot accidentially belong to multiple or no levels).

Please see above, relations do not scale well to planet size, especially relations on relations. You have to care for a lot of things with relations that simple don’t happen for ways and tags. What about a pair of tags “level:min” and “level:max” in this case? Elevators stacked on top of each other are really uncommon, and it would be still possible to map them one on another in such cases.

Yes, a relation would work, but again I feel it’s somewhat unnecessary.

My take on the elevator problem: For routing, having a shared door node between the vertical passage and a hallway would count as a possible exit from the vertical passage. For rendering, we give the vertical passage a level range (e.g. level=1-5).

This is rather off topic, but anyway: I don’t subscribe to the particular religion that believes that relations are evil. In particular they are a fairly simple concept that even not particularly well versed mappers understand, the problem is in reality -too- complicated tagging schemes, and while there are some really bad examples with relations, there are just as bad ones without.

Back on topic, the subject matter at hand is going to be extremely fiddly to edit in any case and will only become “mass mapper” compatible with significant editor support as a consequence it is unlikely that anybody that can’t deal with relations will be exposed to them in a large way.

So while I want the proposal to be as simple as possible, I don’t want to make it more complicated than necessary just to avoid relations for philosophical reasons.

I do however agree that a common node for escalator doors could work, however it differs from escalators and stairs which should work easily with a node on the connected levels (connected by a closed way as in the proposal or a different method).


Yes, I believe that escalators and stairs would need to be treated differently than elevators. The current suggestion in the proposal that all vertical connectors “are accessed via a door” feels weird when this is not necessarily the case in reality.

My favorite idea at the moment: We could use the existing (linear way-based) tagging for steps and escalators instead of inventing a new one specifically for the inside of buildings. The routing problem would be solved, because each way would represent only a single connection, not an entire staircase at once. As a bonus, we would be able to use all existing tags like handrail, step_count and so on, and gain the ability to handle more complex situations where e.g. the up and down escalators are in different places.

The downside is, of course, the additional effort required for drawing a set of stairs on each level instead of a single staircase spanning multiple levels. I’d like to point out, though, that this would not be different from what the mapper has to do for corridors.


as I found it a great idea that Simon is pushing this, I thought of giving it a try and test indoor mapping for buildings I know. I read the original indoor mapping discussion and the whole discussion in this thread.

But let me start with a paradigm that is important to me. Imho it’s of importance that indoor mapping can still be done with the editors out there (I’m using JOSM) without big pain. Also, other mappers that are not aware of indoor mapping should not have problems to extend regular stuff (like buildings, POIs,…). As a third criterion it should be hard, to destruct a mapped building but easy to fix accidental bugs.

That said, I like the proposal and especially Tobias’ changes to it. I think removing all uses of relations gives it a big advance in usability without loosing expressiveness. However, there are imho still some missing parts and some parts that could be changed. I’ll try to share my findings, even if I don’t have a solution.

  1. There should be an indoor=level to cover the complete area that belongs to this specific level. This makes it easier when not everything of the building is covered for each level or when different building parts have different level heights and stuff like this. indoor=level can be extended with name=* and height=* tags to further describe it.

  2. There should be an indoor=platform for areas without walls. I consider a indoor=corridor to have walls, but there are many buildings that have “corridors” with holes, so platform could be used here. I’d also suggest to use it for stairways, but see below.

  3. I created some filter rules for JOSM, so I don’t see all levels at once but can select whatever level I want. This is great but induced the question about node-sharing. In my opinion, each level should reuse nodes. That is: if you have two levels which are congruent, they should use the same nodes but two ways. It makes the building clearly represented and it’s quite hard to add two nodes at the same position anyway. The proposal should be explicit about this.

  4. Tagging stairways and elevators is causing headache. When I use Josm to filter level 1, I’d like to see doors/highway=steps/elevator for level 1 only and possibly a simple way to see where I can go from there.

4a: Elevators: I used indoor=verticalpassage for the elevator outline and put a door=yes with level=1;2;3 on it. However, this makes the filter rules more complicated. Also it was not clear, if the indoor=verticalpassage should be mapped once or for each level? The buildingpart:verticalpassage=elevator is a bit strange, too, I’d prefer something else for that.

4b. Stairs: As suggested by Tobias, I made use of highway=steps which sounds quite useful to me. However, it leads to a problem of proper node sharing and I was not able to map this in an easy and simple way. I started to draw a verticalpassage twice (level=0 and level=1). I added a indoor=platform twice (level=0 and level=1) for the connection of highway=steps. By connecting one end of the way to platform with level=0 and the other end to the platform at level=1, one can see the purpose of these stairs. However, adding another stairway from level=1 to level=2 is cumbersome: You can not make node sharing, as the node has to stick with the platform at the level you want to go. Making the nodes congruent is difficult.

Speaking of stairways: What about stairs that are in the middle of a corridor. Or think of a big railway station with escalators just in the middle of the hall? Anyways, I like the current state and for the buildings I tested it made fun to map and was easy enough at the same time. I could represent mostly anything I liked and the biggest missing point are stairways as noted above.

Hello Peda,
thanks a lot for your ideas.
I´m finishing next days proposal for F3DB. (Full 3D building). Idoor is there an importan part.
I use in my work definitions used in building regulations (I´m archtect) used in the western countries, but probably also in the most countries worlswide.
Especially the question with mezzanine floors should be answered.

The first reader of the proposal draft are: Thomas Graichen, Dotevo, Roland Olbricht, Vvovv, Balrogg, Yarl, Skyraster and 2 users wished to remain anonymous.
You´re warmly invited to participate.

I agree with those suggestions. Especially the indoor=platform (or however we call it) is necessary to describe some common situations.

I don’t like the idea of having areas located on different levels share nodes. This would be inconsistent with our current practice where we tell mappers to not insert a shared node at between the street on the bridge and the one below, for example. And it clearly wouldn’t work with most tagged nodes, e.g. for windows and doors which are completely different on each level.

Admittedly, cross-level sharing of untagged nodes could work (with some adaptions to routing engines). However, it still feels odd. If the problem is that it’s hard to duplicate nodes with JOSM without losing the exact coordinates, I’d rather see that fixed instead.

My suggestion for this is to tag them with all applicable levels, e.g. level=1;2 for steps between the first and second level. That way, the filters can still match them.

It’s true that the filter rules are not trivial. Switching between levels is something where a JOSM plugin would be very nice to have in my opinion, so people wouldn’t have to set up the filter rules by themselves.

I believe the mapping of elevator shafts can be generalized to rooms spanning multiple levels:

In the simple case where the room has the same footprint on all levels, I’m in favor of using only one way and a level tag with semicolon-separated values.
In the more complex case where a room has different footprints on each level, however, I think using a relation (type=room?) combining multiple outlines is inevitable.

These examples are exactly why I think the “vertical passage” concept doesn’t really work well for stairs.
My suggestion is to use highway=steps for these. The tricky part is how to connect them to the hall/corridor surrounding them. I’m not sure yet, but one possibility would be to connect them to an inner ring of the corridor/hall multipolygon surrounding them.

To conclude this lengthy post, let me say to Peda thanks for actually experimenting with mapping this. And I hope Simon will continue working on this, I like where this is going. Perhaps it will be sensible to eventually merge ideas from both this proposal and Marek’s into the ultimate solution.

Dear friends,

pleas take a look: ( Full 3D Building)
This is an first shot but shows some ideas for development of ultimate solution.

Some parts are not described, especially what happens when the walls are smaller as definde building:level height.
Next sketches comes soon.


Could you give some reasoning for adding explicit paths to your suggestion?
It adds even more data that needs to be present for a functional model (instead of trying to keep it to a minimum), the historic IndoorOSM implementation shows that it is not really necessary for routing.

  1. Routing backward compatibility
  2. Compatibility with Open Geospatial Consortium definition

I personally believe we don´t need it in future because navigation understand area routing.
Recently is path routing easier to realize for the most applications.

@Simon: can you update your proposal to the current state of the discussion?