Proposal talk:Level
I'm not quite sure about the reuse of the site-relation. A building level is somewhat a subclass of a site though and it doesn't qualify for type=level. I have no idea yet for a better solution though. --Grille Chompa 12:23, 13 May 2009 (UTC)
- I also wonder what's the reason for using a "site" relation. The standard handling for sites will probably be of no use anyway. What's the problem with type=level? --Tordanik 09:49, 27 May 2009 (UTC)
compatibility with building relation
This proposal should probably be made compatible with Relations/Proposed/Buildings. To do this, I'd suggest to simply use the building relation, but allow to add "level" members to it. These would be level relations as proposed by this proposal. Of course, those objects that are already part of a level relation wouldn't have to be added as "contains" members. The building relation is important, imo, because it allows for a middle ground of details (more detailled than what we currently have in most places, but less effort than level-precise mapping). --Tordanik 09:49, 27 May 2009 (UTC)
- A pedestrian bridge with a staircase and an elevator over a railway has levels, but is no building. A subway station with several basement levels is no building. These shall not be rendered as buildings and that's why level does not imply building.
--Lulu-Ann 00:25, 28 May 2009 (UTC)
- Of course, a level relation would only be a building level if it was part of a building relation. For bridges etc. we could still use your "3d-object" type. For real buildings, however, additional features like support for address information (features that are not necessary for other 3d structures) are desirable, and I see no reason to use two relations for that case. --Tordanik 10:15, 28 May 2009 (UTC)
Why a level relation?
Using relations inside relations seems like a rather complicated solution for something that could be implemented using tags (level=*) and a single "3d-object" relation. For the case that a feature has multiple levels, we could explicitly allow semicolon-separated values. Have I missed some problem with that solution? --Tordanik 14:01, 20 June 2009 (UTC)
- I propose a relation for each level in a 3-D-Object. If there are two 3-D-Objects next to each other, and both have a level 2, then you might assume that there is a connection. By collecting all objects in one level in the same building in a relation, these buildings are not accidently merged. --Lulu-Ann 12:20, 21 June 2009 (UTC)
- I don't see why adding the features directly to the 3d object relations (instead of adding them to level relations which are then added to 3d object relations) would make it harder to find out what 3d object a feature belongs to. --Tordanik 12:27, 21 June 2009 (UTC)
Per-object Is_on:level proposal
This brings several consequences compared to the above Relation and below 3D-Relation proposals :
- all objects of a same level are not anymore part of a relation (eg. a polygon containing same-level entities), but just tagged with a level number
- but all level-tagged objects of a same building/area/"levels container" are in a same single Relation possibly looking like a closed polygon forming its outer bounds.
- the parent-child relation of the level-tagged object is only qualified with an is_in:level=integer key-value pair
Is_on:level=levelNumber (eg. -1)
//all objects with a Is_on:level key from a same area/zone/building belong in the same non-specific Relation
(See the Is_in Key page ; above we just invented the Is_on key on the same principles)
Hello, I added a different proposal "Per-object Is_on:level proposal" directly on the page. Can you comment on it ? Thanks for our collaboration and take care !
--Myselfhimself 19:21, 19 December 2009 (UTC)
- I have moved it here. Can you please make your own page for concurring ideas? Thanks. Everything else is just confusing.
Level Maps
Hi there,
I have started to draft a generalised approach to stacked structures with levels and vertical ways. It replaces the level relation with a so-called level map relation, mapping objects to levels. This would solve the level problems of stairs, lifts, etc. See Relations/Proposed/Level_Map.
Marl 19:22, 26 September 2011 (BST)
Too much for the more common case
I believe the most common case of mappers wanting to indicate levels of objects is not the creation of 3D building maps, but the much simpler case of indicating that an ordinary point of interest (such as a dentist office) is not at street level and should not be confused with whatever is at street level.
As such, it would be much simpler to allow the use of the existing layer= tag on more kinds of objects, with a defined rule as to how the layer numbers should map to building floor designations (in a language independent manner). For instance it could be defined that layer=0 is the building level closest to the nearby street, and each increment/decrement by 1 layer corresponds to one floor.
The exception is when the street is already tagged with a non-zero layer, in which case the street level would be in the same layer as the street. Another exception is when two buildings with different per-level height are interconnected at multiple levels such that one building has more floors between the two interconnects than the other. In that case, the layers for the building with bigger levels would simply skip some numbers. This is also suggested for any obviously double-high levels such as a floor entirely of ballrooms and gyms.
This would be much simpler to deal with than a new almost-the-same-but-not-computer-comparable level tag. Existing renderers will handle layers as they already do (unless they have explicit code not to), routing software will handle this the same way it already handles layers in complex freeway junctions etc.
For precise heights, the best solution would be to allow the GPS altitude to be part of the data in general. This data is already in many uploaded tracks.
This simplified proposal would still support full 3D maps of buildings, but would be much easier to handle for those not working in that special field, and would typically not require changing of tags when adding a 3D map of an already heavily tagged building.
However I note that someone has defined a level= tag with similar semantics, except the complexity of interacting with layers and the (misguided I think) suggestion of using non-numeric values.
In any case, treating level as a z coordinate rather than an extra relation makes things a lot simpler. Jbohmdk 05:34, 25 August 2012 (BST)
- layer unlike level does not specify that 2 objects on the same level/layer are actually at same height, elevation or logical floor and it cannot be redefined like that without changing the semantics of large parts of the world that we have already mapped. It makes a lot of sense to group objects to logical levels, the question is just how. RicoZ (talk) 10:46, 13 December 2013 (UTC)