Towards a unified and simple indoor mapping scheme

  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 :slight_smile:

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.

I think there should be indoor POI visible on main map - for example cinema in big shopping center. On the other hand there are also POI that make sense indoor only. In my opinion we should have some way to notice at least one of such a situations, to distinguish between them.

Yes, different, but that does not matter here. The question is how to distinguish two level high room from two identical rooms on both levels? In first case doors are on first floor only. Probably we should just add proper high to such a two levels high room and left that space empty on next floor (I’ve done this that way). Maybe indoor renders should be able to do something with that…

This idea if OK for standard walls (where thickness does not change on one wall). If we have wall more than 1 meter thick and have a recess in it (with wall 30cm on that part) we will have a whole in wall way or we have to draw nonexistent perpendicular walls between them. The next problem I found were circulars rooms (see Aula on first floor in that building) and rooms with cut corners. I think indoor map is not just a schema to forget about such a situations.

In most (at least) cases you are right. Is there any render, which work with proposals without relations?

BTW Thank you for your answer.

I opened an issue for rendering toilets and other things lighter if they are access=private. This would be a start for the toilet problem. I am lucky that the 4 toilets of my demo building are above each other, so only one is rendered. :slight_smile:

Yes, this is a real usability problem! I used repeat_on=* for my demo building, but my change to the wiki was rejected. See Talk:Simple Indoor Tagging for more details.

Hello all,

regarding routing, is there a working example using this tagging schema? If so, which is the routing engine used?

We have been doing some tests with OpenTripPlanner and we think it is possible to make it work but the mapping task is complicated. I mean that using area routing for corridors and other parts requires to expend quite more time in the mapping task making sure that an area shares a side to the next one but not with others.

On the other side, using a “traditional” navigation graph (as we did in a previous work: http://www.agile-online.org/Conference_Paper/cds/agile_2014/agile2014_82.pdf)) requires additional drawing but seems to be more practical and require less time.

Comparing both, in our opinion:

1 Simple Indoor tagging (area routing)

  • Requires more time in the mapping task because is more complex
  • Currently, using OTP requires extra tagging: highway=* and area=yes
  • It might require to modify routing engines to avoid the extra tagging

2 Navigation graph

Coming back to the original question, does anyone have a similar experience? And in any case, any opinion/suggestion?

Regards

There are prototype implementations for routing over areas. Have a look at https://translate.google.de/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwiki.openstreetmap.org%2Fwiki%2FUser%3AMaxbe%2FRouten_über_Flächen&edit-text= and the corresponding discussion at http://forum.openstreetmap.org/viewtopic.php?id=23129 .

To supress the rendering of indoor ways at osm.org you can use an tag which isn’t renderd there e.g. highway=corridor. This doesn’t tag doesn’t work for steps, though.

Regards,
Andi

IMHO shouldn’t the following changes be enough?

  • indoor=corridor - collapse to a an edge or use area routing (along the enclosing polygon as simplest option)
  • indoor=room - only allow transitions to other indoor objects via doors
  • indoor=area - area routing including to corridors and other areas, might need to know about indoor=wall
  • special casing of elevators and stairwells

SIT doesn’t disallow the use of explicit ways for routing, but it would be nice if we could get rid of them medium term. There was definitely never the expectation that the current crop of routing engines would be able to handle indoor routing without modification.

Simon