Proposal talk:Level Map

Please start the discussion here, adding topics.

To do

• Interfacing with the level
  • Probably not needed. There is no legacy. Taginfo showed up 15 level relations in total on 9 October 2011.

"level_map" vs. "multilevel"

After having found the concept of level maps, I wondered whether I should choose a good description of what the relation exactly is (a level map) or the main purpose of the relation ("multilevel").

The first option seems to be more helpful in using the relation, the second one can be found easier when searching for a solution. Its similarity to the well-known "multipoligon" could be helpful, too.

For now, I have opted for the description of what it is, waiting for other mappers' feedback.

What do you think?

--Marl 20:39, 26 September 2011 (BST)

I think multilevel would be a better name, as it actually describes what this relation is about. But this name is already used. Also possible: levels or multiple_levels --Saerdnaer 15:06, 26 November 2011 (UTC)

Height Coding

As the concept is about the third dimension, it should include a means of coding heights. Of course, adding heights should be optional, but I think that the option should be given.

The tag height=* is already defined and can be used here, for example for lifts. Instances of nodes with a height=* tag give us a clear information about the height difference between the topmost and the lowest instance of the node. However, we don't know what to do with other node instances.

I don't (yet) feel comfortable about making the height tag a semicolon separated list, because that might confuse renderers.

However, levels don't need to be flat. Node instances are stacked vertically, with a defined vertical distance between levels. So adding the height information to the nodes would be the most flexible method, also being the most work intensive method. So it might be a good idea to allow a level height specification per node. But as soon as there is more than one node carrying the same height information, inconsistencies are expected. So I think that we need a better place whenever the same information applies to more than one node.

Ways can also carry height information. If they are flat, everything is fine. If they are not, we may put deviating information onto the nodes.

We have also got existing stuff in the level relation about individual levels having a height. That works for flat levels only, but something with a different height might be a different level. However, the level relation must be interfaced with this concept anyway.

--Marl 08:52, 1 October 2011 (BST)

Adding height information to the nodes themselves seems not to be a good idea, because the nodes may be used in several level maps and without cross-linking the height tags, it would not be unambigous. So, together with the integrity concerns above, I have dropped the idea of adding height information to the nodes.

As a start, I have added height information (the height of node instances as a distance from some sort of ground level) to the level definition inside a level map and to the role definition. I am surprised that it looks quite complete.

--Marl 14:29, 8 October 2011 (BST)

Any feedback?

Buildings on sloping ground

Note that some buildings are on significantly sloping ground, and so may have entrances at ground level on more than one floor. It's probably not a problem for mapping, but authors of routing software may have to take this into account.

--

Yes, I have thought about an uneven ground as well. Sloping ground or terraces are the least complex variants. Everything is possible here. That's exactly why I chose the wording "the street level ... or the main ground level". If buildings (even bridges and underground structures) are on uneven ground, some main ground level is defined.

Of course, the mapper doesn't necessarily know which one is a building's "true" main ground level. However, if he knows it, he can map it. At the end, he doesn't need to know it, because he can connect all entrances to their particular levels, no matter how they are named. Practically, he might map the level with the most external "ground level" connections as @0, making it the default for external connections and saving time for tagging.

In severe cases (two levels with many entrances each on their respective "ground levels"), two connected level maps can be created. In these cases the level naming on local signs will probably give a good hint what exactly to do.

--Marl 18:55, 13 October 2011 (BST)

Rooms

IF indoor features should really be mapped, then I miss the most important part in your proposal: rooms. I would say, it's more important to map rooms (as polygons with marked door-nodes (entrance=door) than to map footways corresponding to corridors. We need the walls here.

In general I'm not sure about how good it is to map single rooms in OSM yet. Yes, I am the creator of the multilevel proposal linked here, but I'm even not sure if that was a good idea.

Let me explain, why: It's really hard to edit multi-level constructions in the common editors. I would like to see editors supporting this better than it's currently supported, and I know some workarounds to not interfere between different levels, but e.g. in JOSM it includes heavy use of the filtering feature, and that's nothing you can see on the first view and have the idea how to use it.

For the proposal itself I would recommend to visualize better how to use the suggested features in editing. That's more important for mappers than how to render it in maps (which can stay in the proposal, but should not be the only visualized part). It's relatively hard to read and you have more or less to try out everything to really understand what is meant. --Jongleur 16:39, 16 October 2011 (BST)

Thanks for the feedback. Regarding your last point - the how-to: Before doing it, I wanted to see sufficient feedback including from (routing) software developers, so I know whether or not it's worth the effort. So I will start a short how-to this week. I guess that the part that everybody should know is less than half a page.

How-to page started, see Level_Map/How-to --Marl 23:42, 17 October 2011 (BST)

With regard to the rooms: My motivation for the proposal were ways, to get a the pedestrian routing through urban centres improved. As most mappers are more interested in highways than in garden fences and buildings. Of course, the proposal is powerful enough for indoor walls and rooms, provided there is a good tag for them. Walls are very easy. Rooms can be done easily as instantiated polygons (with two rooms, one on each side of the wall, overlapping along the wall line) and much more elegantly (but not that easy) as instantiated 2D or 3D multipolygons. Unfortunately, the multipolygons would be relations as relation members - something that many people seem to hate. If you like, I can include examples for both.

--Marl 18:39, 16 October 2011 (BST)

I am especially interested in being able to map rooms and POIs within buildings, such as waste bins, elevators, escalators, staircases, toilets, cafetarias and eventually fixed tables, fixed chairs as well as bounding boxes for non-accessible areas. I figured out there are multiple proposals dealing with those. Some of them have to be made compatible with this proposal. However if possible all of them should be related with this proposal to encourage people to use them and especially this proposal. See steps, DE:Stairs_modelling, lifts, Proposed features/entrance, Proposed features/entrance/indoor-usage and Proposed features/entrance/door. I'll probably develop a c# render engine in feb, 2011. --andreas.balzer 19:30, 18 November 2011 (GMT+1)

I wouldn't call this relation intuitive

Why did you decide to jam everything into single relation, and not to extend the level relation proposal? Most of strange shortcuts, like "levels=B=Basement@-4;G=Ground floor@0;1@5;2@9;3=Roof garden@13", would make some obvious tags in that scheme. --Zverik 17:24, 18 October 2011 (BST)

I tried to find a way of encoding ways (stairs, elevators, etc.) between levels based on level relations for quite a long time and didn't find an easy solution. Until I woke up on 25th September with the idea of a level map, when everything fell into place. I started to write it down and it worked.

While writing it down, I hesitated putting additional stuff into the level and role definitions. But whenever I thought about how to break it up, I did't find a place to put the fragments into. The level relations didn't help here:

• the level definition doesn't contain much more than the order of levels in this particular level map. So I can't move them into independent level relations, they have to remain here.
• The attributes of a particular level defined here may well be separate tags of the level map relation or a different relation (which would be usable only as a member of this one level map, more or less a slave). I didn't want to put them into such a slave relation, because that would break one of my design criteria (no need for nested relations, at least for now) and it would generate unnecessary work. The first solution (putting them into separate tags of the same relation) was much more appealing to me, but I feared inconsistencies (levels with attribute, but no definition or the other way round). At least that would disturb the manageability. At the end, I did it for the foreign language translations, because that would have been too much for the level definition strings to bear.

I was surprised about your word "shortcuts", because I could find only one, the "@" sign, as a shortcut for "at (a certain height)". The rest is just a semicolon separated list. Not of shortcuts, but of words (or abbreviations on elevator pushbuttons) that the mapper writes down here.

What I do know is that my description of the tiny concept is cluttered with big number of constellations that I have tested and described, so you don't have to rethink everything from scratch when judging the proposal. I will reduce the focus in the first part of the how-to, exposing the easy parts of the concept and linking details sections further down, handling special cases, such as your example (to be used only if there is a short and a long name for some floors and the mapper is determined to encode the height differences of the levels).

However, I will take your feedback as another request to make the introduction easy. If you know how to move things out of these strings without increasing the complexity or the mapper's work significantly, I would really be interested.

--Marl 20:06, 18 October 2011 (BST)

I've spent three hours reading this proposal and the related how to. I have to admit I don't get it. The idea of having a relation to introduce level naming is good. Everything else is just not 'fluid' for me to get. I favour adding a level tag to each node and way if it is located in a level-mapped building. Having some nodes that appear at specific levels or at certain intervals is not only difficult to understand but also difficult to render. You have to run through the whole building to evaluate the whole building for a small view of a single room. Proposed features/indoor is much easier to understand and much more compatible with other standards and proposals. Can we somehow merge this proposal with these to take the best ideas? just my 2 cents --andreas.balzer 19:58, 18 November 2011 (GMT+1)

First, thanks for spending so much time on my proposal. Yes, something in the proposal seems not to be intuitive. However, I haven't got your points (yet) either:

• A level tag at an element works only if the element belongs to one level only. It doesn't work as soon as the element belongs to different level systems (two adjacent buildings or just an elevator with "wrong" buttons).
• Nodes appearing on different levels - if you know only a part of a building, you can easily map the occurrences you know, without breaking anything. It is easy to add occurrences. There is no need to run through the building. I see, the how-to section "extending a level map" is still empty. With regard to rendering - if you render 2D, you don't need to do anything, it just works (of course, I have got ideas of rendering it anyway: one shadow for two occurrences, two shadows for more than two; the expanded data format that I have described in the software support page is prepared for that). If you render 3D, you need the expansion. I always had the expansion algorithm in mind when adding a feature. It should be very straight-forward. However, I haven't written it down yet.
• Yes, most other proposals work perfectly with routers without expanding. But I don't see how (2D) rendering works with them. This proposal supports 2D and 3D rendering, in particular because of the easy calculation of height differences between the levels. Even sloped levels work perfectly, as well as slops between levels.

And last, but not least, I'm really concerned about the manageability of levelled structures without level maps, because of the number of elements to maintain and resulting consistency problems.

--Marl 19:39, 19 November 2011 (UTC)

I do not understand the rationale

I agree that level mapping is useful. However, I still don't understand the advantages of this particular proposal. Neither of the reasons mentioned in the rationale seem convincing:

• "people are not used to this idea" - People are not yet used to any method of indoor mapping. But conceptually, modelling two ways on top of each other as two ways whose nodes have identical lat/lon coordinates, but different level (or ele) coordinates, seems the most obvious approach.
• "the editor software has no support for it." - JOSM has support for filters that can be used to only show elements tagged level=x (and their children, such as nodes within a way on that level). This means that you can edit each level in a normal 2D manner. No need to prepare floors elsewhere, and if you want to understand the building once it's ready, you just switch the appropriate filter back on.
• "the problem of which end of the stairs is connected to which level." I don't see why this is a problem. The end that shares a node with a level=4 way is connected to level 4, while the end that shares a node with a level=5 way is connected to level 5.
• "Another goal of this concept is to avoid nested relations." - You could avoid using relations at all for most buildings. level tags and a building outline containing all the indoor elements geometrically should be enough to cover basic buildings. Relations for levels are somewhat useful because you can add tags (such as level names) to them. Then again, your proposal uses a tag with a list of values instead. A tag like that could just as easily be added to a building outline or a single building relation, thus avoiding the need to create a relation for each level.

--Tordanik 01:28, 26 October 2011 (BST)

Thanks, Tordanik - that's quite comprehensive. As some of your points will probably be discussed, I have tried to create a thread for each one of your points.
Overall, I think that the "hard way" of mapping stacked structures that you are following now is nothing that we should expect the average (or even advanced) mapper to do. We have got computers that can instantiate single OSM database objects easily. With level maps, mappers can understand existing structures very easily and produce new ones quickly. I think that even advanced level maps need less skills and far less time to produce than a very simple building consisting of stacked, distinct OSM objects. --Marl 21:01, 27 October 2011 (BST)

Mapping stacked structures - obvious or not?

OK - to me personally, it is obvious. To you (Tordanik), it is obvious as well. Having wrote "no obvious way", I meant the situation of one of the currently 484556 mappers having found that, for any reason, he wants to map levels. He starts is favourite editor, loads the area and maps the first level. Starting the second one, he finds that everything he tries do add keeps snapping to the existing level. He can add multiple ways at the same place, but they share the same nodes and "overlap". Our poor mapper gives up. --Marl 21:01, 27 October 2011 (BST)

We need to differentiate a bit here. In my opinion, the theory of my suggested approach is very easy to grasp: Just map everything as usual, but add a level=* tag that defines the level(s) the object is on. I believe that, given a brief explanation, most mappers could understand this. Do you agree with that assumption?

The not-so-easy part is, of course, to learn how to effectively edit these object stacks in practice - what buttons do I need to press to see only the objects on level 1 / prevent my ways from snapping to objects from other levels / etc.? But this is largely an issue of #Software support. --Tordanik 00:44, 1 November 2011 (UTC)

I agree with you upon the first part. But even though it's obvious, having a closer look at it, for several reasons (including the ones we are discussing here), I don't like using only this approach.

Yes, adding sufficient software support to all popular editors would help at that point (only). --Marl 21:04, 2 November 2011 (UTC)

People used to this idea - why?

"... People are not yet used to any method of indoor mapping. ..." Tordanik 01:28, 26 October 2011 (BST)

That's only part of what I meant. My other point here is that having an editor window looking from above onto levels hidden below each other seems, according to my perception, not to be the most comfortable idea. I think that it's not special to indoor mapping, but more about handling three dimensions on a flat screen in general. Not surprisingly, my proposal handles the third dimension on a purely descriptive level. --Marl 21:01, 27 October 2011 (BST)

Stacked distinct elements with level tags deal with the 3D editing problem by letting the mapper approach each level as an isolated 2D mapping task. The interactions between different levels are kept to a minimum (= features that actually affect multiple levels, e.g. stairs). This is not the case with level maps: With your proposal there is a lot of interaction between different levels due to shared geometry, so the mapper actually needs to think in 3D quite a bit more. --Tordanik 00:44, 1 November 2011 (UTC)

I wouldn't say that the shared geometry is interaction. However, the mapper should know which parts are shared. Of course, this model can grow slowly, while painting the several pieces of a level. I think that the horizontal parts of the levels are easy in both approaches. The interesting ones are the sloped and vertical parts. And I think that level maps are far easier there. --Marl 21:04, 2 November 2011 (UTC)

Software support

"... JOSM has support for filters ..." Tordanik 01:28, 26 October 2011 (BST)

Abolutely. Implemented recently. Of course, it helps - if you know exactly what you are looking for. If you don't know what goes on, you will see that the object you clicked on is member of a relation. In your case, it's a level, in my case, it's a level map. When you try to investigate what that structure is about, you have to guess about other levels (using level relations) or have an overview over all levels and members (opening a level map relation), highlighting each element while clicking through the member list). Of course, I have seen a building outline as part of one of your buildings that gave me a good, although incomplete hint. Overall, I wouldn't say there is software support for independent level structures. I would say "there is at least one editor that can be used if you are and advanced user". --Marl 21:01, 27 October 2011 (BST)

My impression of the situation is as follows: Advanced users can already work with independent level structures, although the tools are clumsy and not really fun to use.

But imagine tools that are only a little bit more advanced. Let's say there was a panel with "elevator buttons" where the mapper selects the level he wants to edit. Objects not on the current level would be greyed out in the background, and of course would not interfere with drawing on the current level. All objects added in this mode would also receive the appropriate level attribute. Would it still be too hard to map a level stack? Technically, what I describe here is simply a different user interface for JOSM's existing functionality (filter + adding tags). --Tordanik 00:44, 1 November 2011 (UTC)

I'm not too sure how hard it would be. I think that it would be harder than a level map. Have you had a look at my real world examples? However, it should be a quite acceptable effort.

But what do you do as a viewer of such a construction? Would you like to scroll through one and the same sequence of elements for every level (or alternatively through every level copy of a certain element), just to verify that they are all the same? And if you find a bug, do you want to fix all copies separately (or at least select exactly the set you need and nothing else before doing the mass change in one step)? If not, how far would you want to drive the software support with heuristics trying to find out which parts might be meant to be level copies of what? ... multiplied by the number of editors? I feel that it's a matter of tidyness and consistency. I'm happy to map different geometries on top of each other. I don't like mapping one and the same thing repeatedly if there is no need to do it. To me, it feels like creating garbage that others have to deal with later.

Of course, we need the instances. My proposal is to let software generate them on-the-fly. I think that somebody (possibly I) has to provide some level map expansion code that can be built into routers or converters (mkgmap, etc). --Marl 21:04, 2 November 2011 (UTC)

I have looked at several of your examples, and I have also mapped one building from my area with level tags a while ago: http://www.openstreetmap.org/?lat=48.563378&lon=13.431078&zoom=18&layers=M. It's a shopping centre with only two levels, but it is nevertheless very hard to understand without level filters. Of course the two levels are not identical at all, so your proposal does not really affect this.

But this is in no way an unusual case. A lot of interesting buildings have significantly different floor layouts for each level, and can therefore hardly be mapped without editor support for per-level editing. So when we talk about software support, then imo the question is not whether we add this to editors or add instancing support to routing/rendering/converter applications. To handle buildings with different level layouts we need the editor support anyway, and the only real question is whether or not to also add support for level maps to data consumers.

So far I have not mapped any building with many identical levels. On the one hand, it might be nice to use a specialized data model for that case, especially when all levels have to be validated or corrected at the same time. On the other hand, we don't do this for other copy-pasted content either (say, identical housing blocks in some residential areas) and the likelihood that the level layout needs to be drastically changed across all levels due to real-word changes, rather than mapping errors, is pretty low. It also has to be said that, while I'm familiar with relations, most of the 487822 registered mappers aren't. So I'm not yet sure about the editing side of things.

However, as a user of the data, I certainly do not at all like the idea of implementing level map support. Your proposal places quite a burden on data consumers (there is already an enormous number of applications using OSM, a lot more than there are editors) - and I don't mean the processing time, but programmers' time and software bug potential. I appreciate, though, that you consider experimenting with your proposal from the data consumers' perspective yourself. --Tordanik 00:04, 3 November 2011 (UTC)

That's interesting how different we can see buildings. It's true, on your map of the shopping centre, both floors have a quite different layout. Most wall locations differ by 0.3 to 1 meters, in one case 1.8 meters. I can't imagine that this is how the building actually looks like. Apart from these small differences, the walls separating the shops from each other are different on both levels. That's a lot of similarity, with some differences (if I assume that you have added all differences < 1 m intentionally to keep the map readable). And I don't agree with you about editors needing per-level editing support anyway. Level maps can make your life easier also when mapping levels with different geometry. I'm sure that with level maps, it would be much easier to map your shopping centre. Of course, special level map support built into an editor would enable everybody even without knowledge about level maps or relations to map all sorts of buildings.

Regarding the consumers, yes, there are many consumers. From my point of view, there are two questions to answer: 1. How many of them would be restricted if OSM is full of level maps and the consumer doesn't handle them? 2. If some level map expander code is available under acceptable licences (let's say under GPL2+ in C and Java; commercial developers might write their own implementation), what would be the problem? I always saw the problem from both sides and always had the application programmer's view in mind when creating the proposal. And I always saw the option to implement a first fully working version of an expander library and command line tool for general use myself, in case others aren't faster and better than I am. --Marl 21:55, 3 November 2011 (UTC)

I have created a level map software support page today. Would that help you? --Marl 20:03, 5 November 2011 (UTC)

If a library/preprocessor lets me ignore that a mapper has even used level maps in the first place, and is unobtrusive enough that I can just throw it into a software stack (i.e. doesn't affect my choice of operating system or software license, doesn't have a significant impact on performance, and doesn't have bugs that my application would be blamed for), I can hardly complain as a data consumer.

Whether it would make a mapper's life easier - well, I guess we won't be able to agree here for now. I generally prefer concepts that are straightforward to understand and make it easy to "add your first level tag", even if they require a higher number of primitive actions than a more elaborate solution. Maybe the only way to find out is to have ordinary mappers test the different approaches. This probably means that I would ideally document the level-tag based approach and develop a prototype of the editor tool I was talking about earlier, so we could user-test the alternatives. Not sure whether I'll get around to that anytime soon, though. After all, I'm only discussing this issue right now because you happened to start this proposal. --Tordanik 07:38, 6 November 2011 (UTC)

Which end of the stairs is connected to which level

"I don't see why this is a problem ..." Tordanik 01:28, 26 October 2011 (BST)

Yes, I see now. I misunderstood the existing level map proposals until today. Understood that they proposed to share nodes between levels. I checked some existing "levelled" buildings today and found that the nodes are not shared. However, when I thought about it before (having your model in mind without knowing that), I stopped at the point when I fancied an average mapper seeing a stairway and ways ending at nodes a either end and trying to find out which nodes are connected. Of course, JOSM has got the wayselector plugin now, that would do the trick in conjunction with filters. Otherwise, the mapper would probably have tested the connection by moving the node and watching how many ways follow the move ... I think both are not easy solutions. At least not if you compare it with the level map way of coding stairs. --Marl 21:01, 27 October 2011 (BST)

Avoiding nested relations

"You could avoid using relations at all for most buildings ..." Tordanik 01:28, 26 October 2011 (BST)

Yes, agreed. Using level relations XOR a building relation would be comparable to the level map approach from a relation nesting depth point of view. --Marl 21:01, 27 October 2011 (BST)

Why are nested relations bad? If there is clear structure (like Media:Indoor_relations.png) i really like the concept, as it makes converting osm data to other indoor data structures like BIGML easier. --Saerdnaer 15:23, 26 November 2011 (UTC)