Towards a unified and simple indoor mapping scheme

We could add the tags to the level’s shell, though, assuming we decide to keep the shells.

It is true that there would be some duplication between level shells and 3D building parts, which is of course undesirable.

However, the proposal currently includes tagging windows, which (according to the example buildings) would be nodes in the shell. This is something that cannot as easily be done with building parts spanning multiple levels: Doing so would mean inserting nodes for windows from different levels, which might be directly on top of each other, into the same way.

Of course we could find a different solution for window mapping. But as the proposal stands, the shells still have a purpose.

I don’t really see a reason why windows couldn’t simply be tagged on the polygons of the indoor rooms etc (and since we are being fairly complete here :slight_smile: there are rooms which have windows inside). I suppose tagging them on the shell would make it easier for a 3d renderer that otherwise is not concerned with indoor rendering to display them.

Using relations makes it easy for the data consumer to enumerate all relevant objects that belong to one building at the expense of making it somewhat more difficult for the mapper.

I think the question we need to ask is: is there enough advantages to the simplification for the indoor use cases by having at least the building relation to make it mandatory?

I don’t really see a use for the level relation (outside of what has already been said). Once you have all elements for the building you can easily recreate any necessary data structures via the level tag. If we make the relation(s) optional we in any case should not allow “mixed” tagging, otherwise we could just as well do away with the relations completly as there is no advantage to data consumers.

I suspect the more interesting question however are the vertical passages. The current proposal “works” (as in Heidelberg had a working routing implementation) but obviously is broken from an OSM data model pov. A non-relation based way of mapping them may however end up being very hackish. My naive thinking is that it should not be all too difficult to create an edge for routing purposes from a relation containing the exits of an elevator. Given that doing this would be slightly “advanced” mapping I don’t quite see the argument against relations here.

Simon

This is precisely what “we don’t map for the renderer” (proxy for data consumer) and “Relations are not categories” are about.

I agree that for most developers working with pointers is quite familiar, but working with geographic notions is unfamiliar. But then we are a spatial database and should therefore should people encourage to use spatial relationships.

We don’t have a relation for each city that contains all roads, or even worse, a full hierarchy from city to suburb to neighbourhood to street to street section, and that’s because this would signicantly bloat the database. As buildings exist in similar numbers than streets, the same problem would arrive here sooner or later.

No, there aren’t. It’s just a typical fallacy that people are trapped in that have the best intent but haven’t tried out what scales to planet dimensions and what not.

On the other hand, for mappers again tags are easier than relations, because a feature has a definite property (it cannot accidentially belong to multiple or no levels).

Please see above, relations do not scale well to planet size, especially relations on relations. You have to care for a lot of things with relations that simple don’t happen for ways and tags. What about a pair of tags “level:min” and “level:max” in this case? Elevators stacked on top of each other are really uncommon, and it would be still possible to map them one on another in such cases.

Yes, a relation would work, but again I feel it’s somewhat unnecessary.

My take on the elevator problem: For routing, having a shared door node between the vertical passage and a hallway would count as a possible exit from the vertical passage. For rendering, we give the vertical passage a level range (e.g. level=1-5).

This is rather off topic, but anyway: I don’t subscribe to the particular religion that believes that relations are evil. In particular they are a fairly simple concept that even not particularly well versed mappers understand, the problem is in reality -too- complicated tagging schemes, and while there are some really bad examples with relations, there are just as bad ones without.

Back on topic, the subject matter at hand is going to be extremely fiddly to edit in any case and will only become “mass mapper” compatible with significant editor support as a consequence it is unlikely that anybody that can’t deal with relations will be exposed to them in a large way.

So while I want the proposal to be as simple as possible, I don’t want to make it more complicated than necessary just to avoid relations for philosophical reasons.

I do however agree that a common node for escalator doors could work, however it differs from escalators and stairs which should work easily with a node on the connected levels (connected by a closed way as in the proposal or a different method).

Simon

Yes, I believe that escalators and stairs would need to be treated differently than elevators. The current suggestion in the proposal that all vertical connectors “are accessed via a door” feels weird when this is not necessarily the case in reality.

My favorite idea at the moment: We could use the existing (linear way-based) tagging for steps and escalators instead of inventing a new one specifically for the inside of buildings. The routing problem would be solved, because each way would represent only a single connection, not an entire staircase at once. As a bonus, we would be able to use all existing tags like handrail, step_count and so on, and gain the ability to handle more complex situations where e.g. the up and down escalators are in different places.

The downside is, of course, the additional effort required for drawing a set of stairs on each level instead of a single staircase spanning multiple levels. I’d like to point out, though, that this would not be different from what the mapper has to do for corridors.

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