[Tagging] Feature Proposal - RFC - CoreIndoor
osm at tobias-knerr.de
Mon Feb 13 22:42:13 UTC 2017
On 08.02.2017 09:09, Pavel Zbytovský wrote:
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!
More information about the Tagging