Proposal:CoreIndoor

Core indoor proposal
Proposal status:	Abandoned (inactive)
Proposed by:	zby-cz
Tagging:	level=* Data item
Applies to:
Definition:	Updates for Simple Indoor Tagging
Statistics:
Draft started:	2016-12-31
RFC start:	2017-02-08

Current update - WeeklyOSM reception

This proposal was mentioned in WeeklyOSM 342 (Feb 10), citation here:

Pavel Zbytovský would like to extend Simple Indoor Tagging, which he calls CoreIndoor. Sadly most of his extensions are based on wrong assumptions and misinterpretations about Simple Indoor Tagging, which documentation should be enhanced.

I would like to react here: I`ve sent a RFC to tagging list, but havent received any negative feedback since. Thus I would be very glad if the author of the statement above could explain a little (possibly providing constructive thoughts). The tagging list or comment page here are the right place. :-)

Introduction

There has been a lot of effort already invested in the indoor tagging. I researched everything in my diploma thesis (http://zby.cz/thesis) and compiled the core of indoor tagging (which is more of an extension to Simple Indoor Tagging). The key concept is to give full choice of indoor elements, in compliance with OSM methodology. Especially corridors and passages could be modelled by ways (not only areas). Also the level=* syntax was made more robust and widely usable.

Second half of the thesis was modification of iD editor, which might be a good tool to demonstrate examples. After discussion of this proposal, I will update my fork of iD accordingly and make a fresh pull-request.

Thanks to everyone who paved the road with previous proposals, and especially to Saerdnaer who started the Simple Indoor Tagging.

Pavel Zbytovský ~ Zby-cz (talk) 16:04, 31 December 2016 (UTC)

Specification

Full specification can be found in the thesis (English, Czech), here are described only differences to Simple Indoor Tagging. Please, read it first to get a context.

It is numbered to allow easier referencing in comments section. //my comments starts with double slash

(1.) Deprecate min_level and max_level

1. For buildings (building=yes) and parts of buildings (building:part=yes) I suggest to use level range - spanning from min-level to max-level (level=0-8).
2. I suggest to keep min_level=* and max_level=* for compatibility reasons.
       //Consumer can filter by level=* + building=yes, is there any other advantage of min/max level?
3. The non_existent_levels=* is kept as well.
       //Is it really needed? The consumer can find algorithmically - skipping level with no features in it.

(2.) Corridors/stairs can use ways

1. Corridors can be now tagged as standard way highway=footway. I consider it essential to follow the philosophy of OSM - mapping from simple to more accurate. This is where Simple Indoor Tagging is too inflexible by forcing users to map it only as areas.
       //We are used to use it outdoor, so why not indoor as well? :-)
       //Example: Shopping mall in Prague - underground parking, main foot passages and few shops POIs
2. Besides corridors there are usually courtyards or atriums in buildings. These should be tagged as areas, as is common with OSM:  highway=footway + area=yes.
3. I suggest to separate primarily passage areas (corridors), which will be marked with standard ways, and primarily separated areas (rooms), which could be labeled indoor=* according to Simple Indoor.
4. Rooms may be tagged as nodes or areas using the indoor=* features or in minimal case only with door=yes nodes. Again, following the philosophy from simple to more accurate. It is advisable to add ref=* and name=*.
5. Staircases should be tagged by standard highway=steps, typically spanning multiple floors with level=0-1. I propose using the orientation of the path as direction determiner from the lower level to the higher – thus the arrow is pointing uphill. The same applies to any paths/ramps that are lead through multiple floors.

(3.) Decimal level numbers

Level tagging is possible even in decimals if needed to preserve “building numbering” (see below). It is also suitable for mezzanine areas and also for better staircase alignment. (see below)

Decimal level numbers (ground level is shown only for clarity)

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

1. Each element for indoor must have level=*. The syntax allows range (0-2) for element spanning across multiple floors, ie. elevator shaft. Such element is then located in whole range including all decimals. For compatibilty reasons we also allow enumeration (0;1;2), but it is interpreted as discrete values (thus equal to level=0 + repeat_on=1;1).
2. Additionaly each element may use a tag repeat_on=*, which marks its exact repetition on other floors, keeping possible element span. (See table below) The recommended syntax is enumeration (0;1;2). Using ranges (0-2) is also possible, but mind it repeats all floors from lower bound with addition of ones. So repeat_on=0.5-3  is equivalent to repeat_on=0.5;1.5;2.5.

Tagging	Type	Effective values	Examples
level=-1-8	continuous	-1..8	building elevator
level=-1;8;9;10 OR level=-1 + repeat_on=8-10 OR level=-1 + repeat_on=8;9;10	discrete values	-1, 8, 9, 10	amenity footway rooms
level=0-1 + repeat_on=2;4	combination	0 ..1, 2..3, 4..5	atriums big lecture halls stairs/ramps
level=0.5 + repeat_on=-0.5-3 OR level=0.5 + repeat_on=-0.5-2.5 OR level=0.5 + repeat_on=-0.5;1.5;2.5	discrete decimal values	-0.5; 0.5; 1.5; 2.5	nodes in staircases mezannine areas

(5.) Extended floor numbers

Deprecated - see version 1

(6.) Special floor numbering

When special numbering is needed (eg. more zero floors in German “-3, -1, K, E, 1, 2, 4”), the indoor=level element has to be used. All features in "K" level will use level=-1 and somewhere inside building there has to be element with triplet: indoor=level + level=-1 + level:ref=K (usualy level outline way). For navigating/rendering purposes the application has to search for indoor=level element for each level and show its level:ref value instead.

Examples in customized iD editor

• Shopping mall in Prague - underground parking, main foot passages and few shops POIs
• University building in Aachen - complete room plans with Simple Indoor (older proposal version with optional `level=*` xor `repeat_on=*`). Another building here.
• Berlin main railway station - several underground floors + indoor=\* features
• University campus Prague - mapping in progress ;-)
• Another shopping mall - only POIs

Rendering

Possible study of a renderer.

Comments

Please comment on the discussion page.

Some comments in tagging list.

History

• version 1 - before PanierAvide's comment about unnecessary "Extended floor numbers"
• version 2 - current