[Tagging] Feature Proposal - RFC - CoreIndoor

Tobias Knerr osm at tobias-knerr.de
Mon Feb 13 22:42:13 UTC 2017

Hello Pavel,

On 08.02.2017 09:09, Pavel Zbytovský wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/CoreIndoor

as one of the authors of Simple Indoor Tagging (SIT), I'd like to 
comment on each of your proposed changes. So please excuse the wall of 
text below. :)

First, thank you for updating your proposal regarding special floor 
numbering. Using tags on the indoor=level elements is something that we 
always intended to be possible with SIT, and level:ref seems like a very 
good use case of that. I have, therefore, updated the SIT page to 
include the level:ref key along with some example values based on your 

Now to the other points:

(1.) Deprecate min_level and max_level

Here I would be interested in your rationale for this change. It doesn't 
allow us to map things that weren't already possible, so while I don't 
see any big problems with it, it also seems unnecessary to me at the moment.

As for non_existent_levels, detecting these algorithmically can be 
tricky due to the use of level ranges. For example, you might find a 
feature with level=2-4 in a building that lacks level 3.

(2.) Corridors/stairs can use ways

This is probably where opinions will vary the most. The decision in 
favour of area tagging was one of the most fundamental that we made when 
drafting SIT. Because of this, using highway ways for corridors feels 
like a big change away from SIT, not merely an extension.

Consider that in non-OSM indoor maps, using areas is already 
commonplace. While there are various reasons for this, the most 
important consideration is probably that indoor spaces are a lot more 
irregularly shaped than your typical road. And based on my own attempts 
at indoor mapping, I feel this is really the case – even utilitarian 
buildings have sufficiently interesting geometry and interconnectedness 
that compressing them into lines doesn't do them justice.

When you combine the cartographic tradition of floor plans with the 
general trend towards micro-mapping that we are seeing in OSM, using 
areas for an advanced mapping topic such as indoor maps seems like a 
logical choice. And because we are more or less starting with a blank 
slate, we don't really need to be backward compatible with highway 
tagging. In fact, agreeing on using areas right from the start lets 
developers of indoor apps build on that assumption.

(3.) Decimal level numbers

This proposed extension touches on some open questions that will 
eventually need to be addressed, but I feel the underlying problem 
deserves a more thorough treatment.

One big issue, for example, is transitioning between adjacent buildings 
or building parts that have levels at different heights, but are 
connected to each other. With the image in this section, you hint that 
your proposal might be used to map situations like these. However, it 
doesn't really work that easily unless the levels have an identical 
height of "1" in the two building parts (which is far from given).

 From a data consumer perspective, there also needs to be a distinction 
between "real" fractional levels (that would e.g. be listed in a floor 
plan), and decimal levels that appear in the level tag of features such 
as a flight of stairs, but don't function as an identifiable level.

Overall, there is no straightforward solution to non-integer levels that 
I know of, which is why we intentionally omitted it from SIT for now. I 
would have expected to tackle it once the community has more mature 
tools and broader experience with indoor mapping. This topic, if 
explored fully, would probably justify an entire proposal on its own.

(4.) More robust multi-level features and repeated features

As far as I can see, the changes in this section are mostly consequences 
of the decimal level numbers. Am I missing something?

Thanks for reading, and I hope we can work together to make indoor 
mapping in OSM more popular!

-- Tobias

More information about the Tagging mailing list