Proposal talk:IndoorOSM

From OpenStreetMap Wiki
Jump to navigation Jump to search

Indoor vs outdoor tags

In my opinion you shouldn't mix up Tags needed for outdoor 3d rendering like windows, roof, facade, height and building:levels with indoor tags. Therefore I recommend to create two seperate proposal pages. --Saerdnaer 15:18, 1 December 2011 (UTC)

Why not? From a use-case point of view it makes perfect sense - especially when looking at 3D rendering. You create a building model, and you want to render both the outside and inside of this building, so I would do exactly that and mix the tags. --Maru39 10:55, 2 December 2011 (UTC)
But there are also cases where I don't care about 3D renderding, but different floors. We have already multiple seperate out- and indoor-proposals. The discussion just get's more complicated, if we talk about two different things on one page. --Saerdnaer 13:29, 2 December 2011 (UTC)
I also do not see a strong need for a separation of Indoors and Outdoors in our model proposal. Currently, we mainly use existing tags and ideas, so regarding the outdoor appearance, the model does not provide much innovative stuff, doesn't it? --Gomar1985 14:50, 4 December 2011 (UTC)

Namespaces like building:*, buildingpart:* and level:*

I would only use namespaces if there is no other way, as for example there is already another tag with that name. OSM tags are not like XML where you need an prefix, if you want to extend a schema in the right way. --Saerdnaer 15:18, 1 December 2011 (UTC)

Good point. Initially, I wanted to create some kind of hierarchy with this approach. But you might be right - I've changed the model (and the examples) accordingly. But what about the tag buildingpart:name? When I use name instead, the current OSM maps will look strange --Gomar1985 14:47, 4 December 2011 (UTC)
We don't map for the renderes. --Saerdnaer 18:59, 7 December 2011 (UTC)
That is a very good hint/note and I definitely share this opinion. However, others might see this a bit different/critical, because they only want rendered-supported stuff... --Gomar1985 19:12, 12 December 2011 (UTC)
When designing tagging schemes, they should not force users to map for renderers by using existing tags for new features. --LM 1 22:16, 13 February 2012 (UTC)

Building level connectors

You will need to be able to map connectors (escalators, elevators) between levels, and also indicate a connector direction (escalator goes FROM level x TO level y). For elevators there should be a way to indicate connection between levels, and also lack there of (some elevators might go from level 1 to level 10, but not stop on level 2 to 9). --Maru39 11:01, 2 December 2011 (UTC)

This proposal didn't mention escalators and elevators yet. There are at least 3 options I'm aware of. In the following example an elevator stopping only on floor 1, 5 and 10 is use to demonstrate the differences:
I currently prefer the last option for mapping, but the first one for data processing. --Saerdnaer 13:29, 2 December 2011 (UTC)
That is correct - I did not yet mentioned vertical connectors. I will do that in the following days. Yet, I'm not quite sure how to realize it in a proper way in our model --Gomar1985 14:48, 4 December 2011 (UTC)
What about one node with vway=yes and vway:highway=elevator which is member of level=1 relation, and also member of level=5 relation and also member of level=10 relation.--Jakubt (talk) 03:20, 7 February 2014 (UTC)

building:levels

As far I see in your example building:levels is the total number of levels in this building. Other definitions say that it's only the number of levels above ground. So please clarify what it's value means in your proposal and how renderers should act, if there is no height=* Tag on that building. --Saerdnaer 19:32, 7 December 2011 (UTC)

You are right. building:levels should contain the total amount of buildings (with no regard if they are above or below ground). Also the model assumes that level0 is the ground floor, so if height=* is not provided, a 3D renderer should approximate the height by some average value for a level (e.g. 4 meters) multiplied by the amount of levels. For a 2D rendered (birds perspective) this key is not relevant --Gomar1985 19:07, 12 December 2011 (UTC)

Definition of Height

I think there is an issue in the proposal in the way the height key is used. The reference building consists of two parts that are rectangular boxes. What about if you have a building that consists of one box with two towers on top? The height attribute would relate to the height including those towers. The area around the towers would be rendered falsely. I think a height attribute should only be used on rooms and corridors, as even one level might have different heights (two tower example could be such a building). 3D renderers have to calculate the height or use predefined models (the outer shell could be used to define such a model). --andreas.balzer 16:35, 25. Feb 2012

Default values

I think there should be a way to define a default value set for a building for example window size, breast, level height etc. There should also be some global defaults defined in this proposal, which renderers can use if there are no values. --Saerdnaer 19:32, 7 December 2011 (UTC)

Good point. For doors it is "easy" to define a default value for the width and height, but what is the default width of a window? Window breast and window height also should be more easy --Gomar1985 19:07, 12 December 2011 (UTC)

door=*

Why don't we reuse entrance=*? --Saerdnaer 19:32, 7 December 2011 (UTC)

Well. From a semantic point of view, entrance indicates that a door is just an entrance to a room, but no exit (in direction to the corridor for example). That is the reason, why I have choosen door=* --Gomar1985 19:07, 12 December 2011 (UTC)

In my opinion the indoor proposal shouldn't specify how a door is tagged other than using a door=* key. I suggest moving discussions on how to tag doors, windows, etc to different pages.

-- andreas.balzer 13:55, 25 Feb 2012 (UTC)

member roles

Please state how far roles are mandatory or optional. --Saerdnaer 19:32, 7 December 2011 (UTC)

roles are always mandatory for all relations --Sanderd17 10:19, 20 January 2012 (UTC)

indoor=yes

Why an additional Tag? I in my opinion rooms, corridors and levels can be only inside a building. --Saerdnaer 19:32, 7 December 2011 (UTC)

Good point - so the indoor tag can be skipped --Gomar1985 19:11, 12 December 2011 (UTC)
Actually I think we need an indoor tag, or at least an outdoor tag. What about buildings that have some kind of garden without roof in the middle? -- andreas.balzer 16:37, 25. Feb 2012 (UTC)

Building-relation

So the main relation for a building should be type=building, building=yes. Currently buildings are only mapped as multipolygon with type=multipolygon, building=yes. Why create an additional relation, wouldn't it be better to integrate the buildingparts into the multipolygon? Then maps for outdoor-uses can just show the multipolygon-relation, whereas indoor-maps can show more details. -- Skunk 15:21, 16 January 2012 (UTC)

As I understand it, the type=building relation would have to contain multipolygons instead of simple outlines in more complicated situations. --LM 1 22:19, 13 February 2012 (UTC)

Determining building level numbers

"The ground level is always level_0". What is "the ground level"? In some buildings, mostly big ones like malls but also smaller ones with inclined surroundings this is often not clear because there are entrances from the outside "ground" which lead to different (inside) levels.

This also doesn't work for buildings where there are no classical levels (there are ramps with lots of different entrance levels). The latter is not very common, I agree. To get this done well we'd need a real 3D model at least for some cases. Or maybe allow fractional building levels (0.5, 1.5 for your usual split level building). --Dieterdreist 13:13, 20 January 2012 (UTC)

I don't think that determining the level "0" is much of a problem. If the signs etc. inside the building designate any of the levels connected to the outside ground as the "ground level", use that one. Otherwise, you choose at will. --Tordanik 14:01, 2 February 2012 (UTC)
There is still the problem with missing numbers (...-2;-1;1;2... or ...10;11;12;14;15...). --LM 1 22:23, 13 February 2012 (UTC)
Why not using 000.00 numbers for levels? The first three digits represent the usual levels, the first after the decimal seperator represents mezzanine levels and the last digit could represent connectors between two mezzanine or full levels, e.g. to build complex 3D constructions that have curved walls. -- andreas.balzer 14:00, 25 Feb 2012
That seems like quite a complicated code. I agree with decimal numbers for mezzanine levels, but I do not understand the role of the second decimal number... --LM 1 13:03, 8 March 2012 (UTC)

I'd like to propose using a different name for the tag "level" in the level relation. It could be called "zlevel" and this might reduce some confusion. I understand the current level tag to be used as an ordering integer for the floors. It is not intended for labels. In the United States the ground floor is typically called "1". This is the name of the level. It is perfectly OK for the zlevel to be 0 and the name to be "1". Likewise, the Mezzanine may be called "M" or "Mezzanine" and have zlevel=1. I would also leave the option using non-integer values for the zlevel. This may be desirable if a new level is added between existing levels. --Sutter 4:59, 12 April 2012 (UTC)

Data model

I am glad to see this proposal, indoor mapping is really needed. A few remarks to the data model:

Choosing to map what is not there (empty space of rooms/hallways) rather than what is there (actual walls) has some advantages, but brings problems as well. The good part is that by mapping the shape of the rooms it will always be proportional - needed for rendering. Also some spaces are clearly separated, but there is no door between - just open space.

It cannot be assumed though that anything between the outer line and rooms are walls (some rooms go over several floors). This is very common in modern public buildings (most likely to be mapped) and should be solved properly. They are sort of vertical connections, only there is no connections, unless one can fly.

What about an area with a key expressing that there is no floor, e.g. OpenArea=1;2;3 where 1;2;3 represent the levels of the connected area. I wouldn't use vway combinations as they represent a different meaning. In addition I'd suggest a tag indicating that a specific area cannot be accessed, something like nonWalkable=yes.. --andreas.balzer 14:06, 25. Feb 2012

So walls should probably get marked to. That would need duplication of all room outlines or mapping rooms as multi-polygons (needed anyway, some rooms have holes - corridor around the whole building for the simplest example).

Building

Having the whole building in one relation is definitely a good idea. The roles of its members should probably be only "level" to allow fractional levels (not as rare as it might seem). Also vertical connections should be directly part of this relation, since they do not belong to any particular floor

I agree with the proposal to use "level" as the role instead of "level_*" The level integer value is stored separately as a property in the level relation. If this same data appears in two places it is inviting an inconsistency, for example if a user edits one location and forgets to edit the other. --Sutter 5:19, 12 April 2012 (UTC)

Floors

In the proposal all members except the outlines (shell) are buildingpart. That seems like a wasted field. I believe a set of values representing general purpose (rooms, connecting areas, common space, semi-outside like balcony or arcade...) can be found. This would be useful for routing to prefer hallways instead of walk-through rooms.

The doors in the example building are only part of the hallway, not of the rooms. That seems very wrong (even if your routing is working with it). My suggestion would be to connect the room outline with the hallway outline with a short (wall's thickness) way, this would than be tagged as door. It also solves problems with door tagging - see this.

I actually have been trying to update the door proposal (User:Andreas.balzer/door-proposal-version2). Depending on how this IndoorOSM proposal changes I would adapt the updated version. --User:Andreas.balzer 04:10, 29 January 2012
Good to hear that. --LM 1 22:23, 13 February 2012 (UTC)

Vertical connections

Levels.png

As stated above they should belong more to the building that to the floor. There should be two things distinguished the space of the whole staircase and the actual stairs. I suggest the staircase/elevator shaft/escalator area is a special relation - member of building. Only the small parts (entrance places) would belong to individual levels, the connecting elements would be part of staircase relation and connect to entrance points. (see image). Elevators would probably have only entrance points mapped with simple connection between accessible levels.(Similar for fireman poles and ladders - near zero horizontal area)

This could perhaps be used to map multi-level rooms mentioned above.

--LM 1 02:01, 22 January 2012 (UTC)

There are some very interesting thoughts on how staircases could be mapped and rendered (Stairs and DE:Stairs_modelling as well as Proposed_features/Steps_features). It would be nice to see those integrated somehow. --andreas.balzer 04:06, 29 January 2012 (UTC)
I know about it and actually it is quite compatible. I omitted the central line here, because it would make no sense if it was not in all the hallways. Certainly this should be solved consistently inside or outside, there is no need to differentiate. --LM 1 22:26, 13 February 2012 (UTC)

ground floor

> The ground level is always level_0

Shouldn't be like that. Some countries use 1 as a ground floor and 0 as ground floor will break level numbering. Ground floor should be explicitely marked as such, so any numbering scheme may be used for floors. However if we consider buildings which lack floor 13 for example (hotels), we may need two parallel numbering schemes - physical floor numbers (may be 0-based) and "human-readable" level number for each floor.

Yes, while 0-based ground floor numbering makes the most sense mathematically, there should be a place for arbitrary numbering (including M for medium floors, missing numbers (0,13...)) - one that would correspond to elevator labels - this ought to be language based (level:name:en). Our school has stupidly different numbers in Czech and in English (0-based×1-based) --LM 1 20:51, 26 January 2012 (UTC)

Building outline

I haven't had the chance to look detailed into the proposal (I'll do that later today). However I wonder whether there might be an issue regarding building outlines. As far as I understand it the proposal assumes all walls to be 90 degrees to the ground. Actually a building level might have an overlapping level above or below it. In those cases the area between the ground of the level and the ground of the next level has to be specified more detailed. Is it a straight or rounded connection, are there overlapping parts? In addition the facade image has to be splitted into images per level. Currently there is no editor support for it but it has to be added to the data set as well as to editors anyway.. --andreas.balzer 04:42, 29 January 2012 (UTC)

Overuse of relations

This proposal shares the tendency of some alternative indoor proposals to overuse relations. Not every relationship in a data model has to be mapped onto an OSM relation, and considering the problems that human mappers have with handling relations, I suggest that they should be avoided where reasonably possible.

Many buildings can be represented without any relations at all:

  • The "is in building x" relationship is usually implicitly expressed by the feature being geometrically contained within the building area outline.
  • The "is on level y" relationship can be expressed as a level=<number> tag on the feature.

Building attributes then go onto the outer way of the building (or multipolygon relation). --Tordanik 14:23, 2 February 2012 (UTC)

/me supports. Keep it as simple as possible. -- Skunk 06:18, 3 February 2012 (UTC)


Since using the relations plugin in OSM, I believe that human users problems with relations are caused by poor editor support of relations. They also make filtering easier. I am shortly in OSM, but relations just make sense.
  • Something being in a building should not be implied at this level of detail, it can easily be under the building or over it. Not all buildings are strictly rectangular with no holes in them and the more public/important/worth mapping the more likely to have some complicated shape.
  • Also the level relation seems to be useful. You cannot put a clear level label on any feature connecting more floors starting with stairs and ending with big rooms.
And having a different representation of simple houses and complex buildings seems just stupid and more work for everyone. Easy should not compromise the quality. --LM 1 22:40, 13 February 2012 (UTC)


Relations make sense when used well, but unfortunately it is very tempting to go overboard with them. As for your specific concerns:
  • It will be relatively rare to have two buildings or other leveled structures overlapping in such a way that it is not clear which a feature with a level tag belongs to. Tunnels or bridges crossing the building outline will not be a problem, because these will not have level tags and therefore will not mistakenly be interpreted as features within the building. Hence, "usually" implied. In the other cases, just use one, non-nested relation for the entire building.
  • The level tag, in the context of an approach as the one outlined by myself here, would not be intended for labels. It would be used for simple, ordered numeric values that could also be used to define ranges, e.g. for stairs or multi-level rooms. Labels would be something to be defined on the building as a whole, usually just by defining a labeling scheme (most buildings are using one of a few popular variants).
That being said, easy inevitably needs compromise quality if we cannot have both. This is a crowd sourcing project, so making it easy to add and edit data is one of the core ideas behind the whole thing. I also fail to see how using different representations for simple and complex buildings necessarily means more work for everyone. From my perspective, it looks as if it would be slightly more work for users of the data, but probably less work for mappers? --Tordanik 20:07, 15 February 2012 (UTC)
We would probably have a different view on how many relations are needed for it to be overboard. I am fine with quite a lot of them (not infinitely). By saying that "Easy should not compromise the quality" I meant that if choosing, I would usually pick more complicated, higher quality. This proposal seems like a reasonable compromise. (even more detailed would contain 3D outlines with individual node's coordinates tagged, general floor plans that could be inherited for all the levels and changed... - that would (as I see it) bring more complexity than useful information). What you suggested emphasises easiness too much at the cost of detail/quality (my view).
Different tagging of buildings based on complexity brings work for mappers - they have to learn two types of tagging, decide which one to use, remap what is done too simply... This does not mean that there should not be a way to map less detail and add more later/someone else. Altogether the proposed solutions seems easier to work with for me (so it does not compromise easiness or quality in this case). --LM 1 11:11, 9 March 2012 (UTC)

Building entrance/exit.

It is very unclear how the etrances from the building should be tagged. Here are the (sometimes contraversial) pieces of mosaique:

  • It is mentioned that they are nodes having role entrance_exit in the main relation.
  • In the example it is shown that they have role entrance.
  • The markup for notes themseves is unclear, however possibly they are marked as door=*
  • It is not clear if they should be members of ground level floor or not. You mention that door are part of the level relation, but in your example the is no node present.
  • What if the node is marked as door=yes and it is on the edge of the room area? Is it automatically dor to that room? In your article you suggest that entrances to rooms are part of the room relation, however in wiki you model room as area (and in some of the examples it seems that it is sufficient if several nonclosed ways which for together closed loop are in lever relation next to each other).
  • You introduce new door=* to already existing group consisting of entrance=*, barrier=door and door=*. I suggest rather reuse them. The most relevant in this case is widely used entrance=* which is in fact the lowest level of information wh need (point of entry/exit). I would use the door=* scheme in addition in casa that we need to mark other properties of this entrance and when the entrance is not gate, gap in wall or something else. Althought you expressed semantic reservations to use entrance=* in discussion above, in your work you have originally prposed building:entrance=* yourself so it sould not be that bad after all ;)


If you do not mind I would like to correct the proposal to solve the ambiguities mentioned. --Jakubt (talk) 02:55, 7 February 2014 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:IndoorOSM&oldid=2514659"