Mezzanine floors: suggestion to use local naming conventions
Currently I would recommend to use the local naming conventions for mezzanine floors, for example Z for "Zwischengeschoss" in Germany. Also see next subsection. So fractional values should only be used for staircases. An other option could be to introduce a totally new mapping for floor names to numbers, which hasn't to do anything with the local names. --Saerdnaer 12:42, 30 November 2011 (UTC)
- One idea might be to keep the fractional numbering scheme for level=*, and introduce something like level:landing=<value-list> for objects on staircase landings, level:mezzanine=<value-list> for doors on mezannines, and any other level:foo=<value-list> you need. The meaning of a hypothetical
- in such a scheme would be that the object spreads over two ordinary floors, three distinct mezzanine floors and one staircase landing. For a staircase that connects the lot, you'd just use level=* on the staircase object itself. --achadwick (talk) 11:13, 13 March 2013 (UTC)
- I agree with the local names for mezzanine (and all other) floors.
- For staircases I would use the multi-value method: a stairway from 1 to 2 occupies both levels and the nodes where it meets some ways at levels 1 and 2 would make it clear which end is where. RicoZ (talk) 12:49, 13 December 2013 (UTC)
The page is stating that level 0 is always the ground level. But there exists cases where entries of building are placed at different levels; in mountains especially, where front and back of a building have entries at different stages (since ground is not flat).
Generally such buildings have definitions of level numbers (0, 1, 2... -1...), so I suggest that by default the level corresponds to that definition. If only there is no definition of the stage numbers, then one entry has to be defined conventionally at level 0, thus defining the other levels.
Teuxe 12:39, 19 January 2013 (UTC)
- The convention for building:levels=* is to count the maximum number of levels, i.e. the lowest ground level counts. If we use different numberings for different buildings, then we are missing information: We can no longer tell how many levels are above e.g. an entrance with level=0. --Tordanik 00:57, 15 May 2013 (UTC)
- Since in Europe and US buildings start at different level numbers this information is very uncertain without further assurances. Also, level is not even required to have a numeric value. Using any other definition of levels than the locally expected one would cause too much confusion. RicoZ (talk) 12:18, 13 December 2013 (UTC)
- There are different opinions about the values for level. My personal opinion is that level values must be numeric numeric and independent from local naming conventions. OSM data needs to be usable by machines, and how else would you automatically solve e.g. the problem I outlined above? --Tordanik 17:40, 13 December 2013 (UTC)
Local convention "level names" vs "logical numbering" and more issues
It doesn't seem to be specified anywhere whether locally designated level names or some kind logical numbering should be used. For me it looks like the benefit of "counting" floor does not really outweigh the confusion that will arise when we use different level names than the you will find printed in the elevator.
In areas where complex buildings are intertwined or very close there may arise the need to specify to which building a level belongs or possibly a part of a floor-level could be shared by two buildings. RicoZ (talk) 13:59, 13 December 2013 (UTC)
- There are some proposals where relations are used for each level when indoor-mapping a building. In that case, simply adding a name (or ref?) tag to that relation should work. But for a building without such complex construct, I could imagine two approaches:
- A tag like level_naming_system = American/European/...
- A level_name tag on the building with a list of values, one for each level.
- Perhaps it would be ideal to allow both - use the easier first option in the majority of cases, and the second for buildings with special requirements.
- I don't have a suggestion for intertwined buildings. --Tordanik 17:46, 13 December 2013 (UTC)
- Yes, I have seen the proposals with the relations. Something like that would be certainly the cleanest solution. I was wondering if a simplistic solution like attaching some building name label to level-name where needed would be an option - eg level=0-Hilton Hotel for a floor of an airport hotel to distinguish it from the airport floor where it may be located. Not very clean but easy and readable. The real world example, I was looking whether it would make sense to extend the validity of level to eg multilevel roads like the Chicago loop area. I was baffled by the complexity of the area, it is now mapped almost exclusively with layer which makes it quite tricky to understand and verify anything. Assigning a level to the roads seems to make sense but would have to be done so that it does not "conflict" with the levels used by surrounding houses and underground facilities.
- Regarding the more classical buildings, the level_naming_system seems fine at first but after more thinking this as well as building:levels would only work if everything having a level is also tagged with some kind of building relation..one of the proposals. So neither applies for level as it is documented at the moment and it seems in many places it was mapped "the simple way".. I have looked at examples in Munich (around Marienplatz). level_name as a list of names would probably not scale well when only a few of hundreds of floors have a special name - frequently the floors are essentially numbered with a few special labels for street and parking decks and maybe topmost floors. RicoZ (talk) 23:05, 14 December 2013 (UTC)
- Simple_Indoor_Tagging#Advanced_modelling_the_different_levels_.28floors.29 does have something similar to your proposed level_name. create a "indoor=level" outline for the level and then use name and/or level:ref. -- SwiftFast (talk) 14:52, 14 May 2017 (UTC)