Towards a unified and simple indoor mapping scheme

Hi,

as I found it a great idea that Simon is pushing this, I thought of giving it a try and test indoor mapping for buildings I know. I read the original indoor mapping discussion and the whole discussion in this thread.

But let me start with a paradigm that is important to me. Imho it’s of importance that indoor mapping can still be done with the editors out there (I’m using JOSM) without big pain. Also, other mappers that are not aware of indoor mapping should not have problems to extend regular stuff (like buildings, POIs,…). As a third criterion it should be hard, to destruct a mapped building but easy to fix accidental bugs.

That said, I like the proposal and especially Tobias’ changes to it. I think removing all uses of relations gives it a big advance in usability without loosing expressiveness. However, there are imho still some missing parts and some parts that could be changed. I’ll try to share my findings, even if I don’t have a solution.

1. There should be an indoor=level to cover the complete area that belongs to this specific level. This makes it easier when not everything of the building is covered for each level or when different building parts have different level heights and stuff like this. indoor=level can be extended with name=* and height=* tags to further describe it.

2. There should be an indoor=platform for areas without walls. I consider a indoor=corridor to have walls, but there are many buildings that have “corridors” with holes, so platform could be used here. I’d also suggest to use it for stairways, but see below.

3. I created some filter rules for JOSM, so I don’t see all levels at once but can select whatever level I want. This is great but induced the question about node-sharing. In my opinion, each level should reuse nodes. That is: if you have two levels which are congruent, they should use the same nodes but two ways. It makes the building clearly represented and it’s quite hard to add two nodes at the same position anyway. The proposal should be explicit about this.

4. Tagging stairways and elevators is causing headache. When I use Josm to filter level 1, I’d like to see doors/highway=steps/elevator for level 1 only and possibly a simple way to see where I can go from there.

4a: Elevators: I used indoor=verticalpassage for the elevator outline and put a door=yes with level=1;2;3 on it. However, this makes the filter rules more complicated. Also it was not clear, if the indoor=verticalpassage should be mapped once or for each level? The buildingpart:verticalpassage=elevator is a bit strange, too, I’d prefer something else for that.

4b. Stairs: As suggested by Tobias, I made use of highway=steps which sounds quite useful to me. However, it leads to a problem of proper node sharing and I was not able to map this in an easy and simple way. I started to draw a verticalpassage twice (level=0 and level=1). I added a indoor=platform twice (level=0 and level=1) for the connection of highway=steps. By connecting one end of the way to platform with level=0 and the other end to the platform at level=1, one can see the purpose of these stairs. However, adding another stairway from level=1 to level=2 is cumbersome: You can not make node sharing, as the node has to stick with the platform at the level you want to go. Making the nodes congruent is difficult.

Speaking of stairways: What about stairs that are in the middle of a corridor. Or think of a big railway station with escalators just in the middle of the hall? Anyways, I like the current state and for the buildings I tested it made fun to map and was easy enough at the same time. I could represent mostly anything I liked and the biggest missing point are stairways as noted above.

Hello Peda,
thanks a lot for your ideas.
I´m finishing next days proposal for F3DB. (Full 3D building). Idoor is there an importan part.
I use in my work definitions used in building regulations (I´m archtect) used in the western countries, but probably also in the most countries worlswide.
Especially the question with mezzanine floors should be answered.

The first reader of the proposal draft are: Thomas Graichen, Dotevo, Roland Olbricht, Vvovv, Balrogg, Yarl, Skyraster and 2 users wished to remain anonymous.
You´re warmly invited to participate.

I agree with those suggestions. Especially the indoor=platform (or however we call it) is necessary to describe some common situations.

I don’t like the idea of having areas located on different levels share nodes. This would be inconsistent with our current practice where we tell mappers to not insert a shared node at between the street on the bridge and the one below, for example. And it clearly wouldn’t work with most tagged nodes, e.g. for windows and doors which are completely different on each level.

Admittedly, cross-level sharing of untagged nodes could work (with some adaptions to routing engines). However, it still feels odd. If the problem is that it’s hard to duplicate nodes with JOSM without losing the exact coordinates, I’d rather see that fixed instead.

My suggestion for this is to tag them with all applicable levels, e.g. level=1;2 for steps between the first and second level. That way, the filters can still match them.

It’s true that the filter rules are not trivial. Switching between levels is something where a JOSM plugin would be very nice to have in my opinion, so people wouldn’t have to set up the filter rules by themselves.

I believe the mapping of elevator shafts can be generalized to rooms spanning multiple levels:

In the simple case where the room has the same footprint on all levels, I’m in favor of using only one way and a level tag with semicolon-separated values.
In the more complex case where a room has different footprints on each level, however, I think using a relation (type=room?) combining multiple outlines is inevitable.

These examples are exactly why I think the “vertical passage” concept doesn’t really work well for stairs.
My suggestion is to use highway=steps for these. The tricky part is how to connect them to the hall/corridor surrounding them. I’m not sure yet, but one possibility would be to connect them to an inner ring of the corridor/hall multipolygon surrounding them.

To conclude this lengthy post, let me say to Peda thanks for actually experimenting with mapping this. And I hope Simon will continue working on this, I like where this is going. Perhaps it will be sensible to eventually merge ideas from both this proposal and Marek’s into the ultimate solution.

Dear friends,

pleas take a look:
https://wiki.openstreetmap.org/wiki/F3DB ( Full 3D Building)
This is an first shot but shows some ideas for development of ultimate solution.

Some parts are not described, especially what happens when the walls are smaller as definde building:level height.
Next sketches comes soon.

Regards,
Marek

Could you give some reasoning for adding explicit paths to your suggestion?
It adds even more data that needs to be present for a functional model (instead of trying to keep it to a minimum), the historic IndoorOSM implementation shows that it is not really necessary for routing.

1. Routing backward compatibility
2. Compatibility with Open Geospatial Consortium definition

I personally believe we don´t need it in future because navigation understand area routing.
Recently is path routing easier to realize for the most applications.

@Simon: can you update your proposal to the current state of the discussion?

As I mentioned, it was not thought of as a proposal, but more as a straw man. But I’ll update it asap.

The page https://wiki.openstreetmap.org/wiki/F3DB is recently updated by other colleagues involved in the proposal development.

There is also space for suggestions and discussions. Everybody is warmly invited to cooperate in. As mentioned: we are a group of mappers and developers interested in fusioning of 3D and indoor approach in the new specification.

The page: http://osmtools.org/indoor/#lat=51.23567&lon=22.71526&z=18 should be redeveloped according to the new proposal.

Some some programmers are already working on the development of JOSM plugin for F3DB mapping.

An article about this idea is published in the August issue of Geospatial World.

Excluding things like window mapping and roof mapping (which are only loosely related to indoor mapping and should get their own proposals imo), I see two major differences between Marek’s suggestions and what we have previously discussed here: The use of ways to support routing, and explicitly mapped walls.

I agree with Simon that ways for routes would not be necessary (with the exception of steps which use directional tags for incline). Indoor mapping is a completely new topic for OSM, so it would be a good opportunity to introduce area-based routing.

However, I like explicitly mapping walls. No only does it enable Marek’s solution A for mapping door directions – which I consider the best available soution –, there are also a lot of examples where the concept that corridors and rooms automatically have walls are problematic.

Of course,
ways are not necessary for area based routing. The algorithms for area routing ale well know.
On the other hand, there is no real need to remove classical vector routing from generalized approach which for example exist in Open Geospatial Consortium.
This is the way to make our project more universal and compatible with existing solutions.

I also prefer solution A for mapping of door directions. It is mathematically clearly. Solution B does not do that.

About your question: “there are also a lot of examples where the concept that corridors and rooms automatically have walls are problematic.”
We have discussed this (obviously) problem quite a long time with Thomas Graichen.
The walls are not necessary. One wall CAN be drawn over the border line of corridor or room, but it is not a necessary condition.
Walls represents only the physical existing divisions between rooms, which are defined by areas.

Sorry for this unclear description on the wiki page we are still in work and you are warmest invited to supplement missing or confusing information.
Best regards,
Marek

Sorry if I phrased this in a misleading manner. I like that your proposal contains tags for mapping the physical walls. Other proposals (such as the one posted by Simon in the first post of this thread) didn’t have that clear distinction between the areas for the rooms and the physical divisions which would lead to various problems.

Ok, understood

There is an invitation for preparing of OSM training material which can be powered by EU indoor project:

Preparation of training material:
This will be based on an interactive training framework that was developed. Currently, among other training material, we are preparing material for IndoorGML, Indoor LBS etc. I was wondering whether Community would be interested in supporting the creation of a training module on Indoor OSM. Please note that all the training material will be open, free to access and will have a Creative Commons Share-Alike license (unless OSM had different required). Training material could include slides, videos etc. and could be beneficial to help spread the “indoor OSM” voice out.

Let´s search for some objects, started by very simple and at least complicated for showing how it could work.
Is somebody interested in participation?

I’ve had a good look at the F3DB proposal, IMHO the main problem with it, is that it doesn’t really support a “simple” model and that the common case (aka rooms with walls and doors) already require numerous tags, further it doesn’t reference simple POI tagging. I further think it is clear that adding ways outside of escaltors and stairs is unnecessary and given that we do not need to be backward compatible with anything existing including OGC should simply be dropped. A futher small nitpick: numerous of the proposed tags don’t have a suggested value range outside of “*”.

Now it is clear that having a facility for wallless areas and individual walls is a good thing. The IndoorOSM 2.0 proposal could be more explicit in doing something along the lines of (note doing it this way makes is substantially simpler for data consumers in that there is exactlly one “new” key that has to be supported)

indoor=room - classical room with walls
indoor=area - area with no implicit walls
indoor=wall - single wall element

…

I’m glossing over zones here, obviously indoor=zone would be possible, just not sure if the destinction is useful.

The IndoorOSM 2.0 straw man currently lacks a suggestion for tagging stairs etc, as Marek points out using the normal tagging scheme will cause issues with rendering, however the above scheme can simply be extended to include

indoor=stairs
indoor=escalator
…

The rest of the descriptive tags from Mareks proposal can remain the same and I believe the door proposal could potentially seperate out as it is useful in its own right (just as Tordanik is proposing for windows).

Simon

I’ve updated https://wiki.openstreetmap.org/wiki/IndoorOSM_2.0 to reflect the discussions to now.

We’ve further worked hard on this proposal. It can now be found here: https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

We think that this proposal is simple and holistic at once and ready to be used. Anyhow, we’d like to hear your opinion if there’s something we missed. Please comment either here or at the proposal’s discussion page.

If someone wants to use the long weekend (at least in germany) for coding (extending osm2world or what ever) i put a building mapped full with the simple indoor tagging proposal.
It has 92 rooms (using one and two levels), corridors, walls, toilet rooms (male, female, wheelchair), stairs, doors, entrances, elevator, ref for all rooms.

All details could be downloaded with the overpass turbo link: http://overpass-turbo.eu/s/5hj
Had no time for building overpass links for each levels. This have to work with
level=0 AND level=-1-3 AND repeat_on=-1;0 AND repeat_on=-1-2

Have fun!

I’ve added indoor map for one building and found few problems with (possibly all) indoor mapping proposals. The building is here: http://osmtools.org/indoor/#lat=50.86483&lon=15.68211&z=18 (just to know it easier what are we talking about).

1. indoor-only POIs. I don’t think there should be so many toilet icons on the main maps, however the only ways to mark an indoor toilet is to put amenity=toilets or just give it a name=WC (or similar). There exists also POIs which have sense only indoor - in that example there are dean office, student government office, student and staff-only library, etc. I think we need something like indoor:amenity, indoor:office tags for indoor only POIs (however some indoor POIs can be marked using standard tags, if POI have sense for outside-building view). With current solution (and current renders) it is almost impossible to find a toilet in this building (yes, they are in different places on each floor - do not ask me why, but it is done that crazy way) ;).

2. I’m still not sure, what with rooms two floors hight? Should I left that space empty on next floor? Currently I’ve done it that way (see “Aula” on 1st floor - on 2nd floor we still have Aula room with no entrance from there).

3. doors and windows - even with level filters it is difficult to make them on particular levels only. On the other hand I really can not understand why do I still see propositions door=yes, width=* instead of door=yes,door:width=* and similarly for windows - that way we can have the window exactly over door (as it usually is in real world). With “opening_hours like” tagging schema we can make all the windows and doors from all levels in one point (of course with door:level and window:level or similar), if applicable (all from “one over another”).

4. stairways - in that building each level is almost twice as high as normally, so we have rooms under stairs - see the WC on east side of floor 0. For that reason stairway on level 0 are drawn only to half way between levels. It could be a good idea to have common points between levels there, but it is not - with path-like solution here we would need few lines one exactly over another (n-1 lines for n floors - I assume one line for one stairway between levels here; maybe we need “opening_hours like” solution here… but what with connections between stairs and floors then?).

5. I hope you like my way of drawing walls here - most of them are more than 1 meter thick - hence I left space in all such a places, like we do usually with landuses with something in-between ;). That way it is possible to see the real shape of inside part of each room.

BTW. I do not understand your fear of relations. In my opinion in OSM we do have points, than we have lines as (organized) sets of points and relations as (organized) sets of lines (and points, and relations). Is a relation really more complicated thing, that line is? I don’t think so. It is also easy to destroy a line moving all points of it - we will not see line was edited (at least not in that line history). Points being the elements of line can also have their own tags. Hence where is the real difference - I think in programs for editing only (it is still to easy to destroy relation by accident - the reason is relations are not displayed properly!). The basic is that line and relation is the same thing - the (organized) set of * (if * means “points only” then we call that relation “line”).

PS. Everything written in this post is my opinion only. I can be wrong, it is also possible that I do not understand something (or even I don’t remember something I’ve read in proposals).

I believe that this is a temporary problem as long as renderers have not yet been told to exclude indoor features (e.g. based on the level tag) from display. This will probably be fixed once there is a large enough amount of indoor data mapped. I believe it’s worth to accept this temporary issue because it allows more natural tagging.

In the “Simple Indoor Tagging” proposal, you can set multiple levels for a room, like level=1;2. You appear to be using a different proposal, though?

As far as I know, the two latest indoor proposals suggest not leaving space between rooms to represent walls. Of course there are merits of either approach, but we need to agree on something.

In theory, that is of course true. But as you said, it’s about presentation. If editors presented lines like they present relations (i.e. displaying a list of nodes instead of drawing an intuitively understandable shape), then lines would probably also be considered complicated.

Unfortunately, it isn’t easy to fix that problem. Because relations can be used in so many different manners, this is not really possible without adding specialized support for every single relation type. And ultimately, relations are simply not necessary for indoor mapping most buildings in my opinion, so we can avoid the whole issue.

I think there should be some difference between a toilet, which is part of a restaurant, and a toilet, which stands on its own (like a “Mc Clean” in several big train stations, bigger than some “Mc Donald’s”, or those small one-toilet-buildings). Maybe access=customers could be enough, but imo it’s more than just “in a building or not”.

Or – a spontaneous idea – maybe tag “real” toilets as amenity=toilets, their single toilet rooms with something new and a toilet in a restaurant as toilet rooms without amenity=toilet.