You are not logged in.

#26 2014-07-25 21:36:07

marek kleciak
Member
Registered: 2010-10-11
Posts: 8,417

Re: Towards a unified and simple indoor mapping scheme

Ok, understood 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?

Offline

#27 2014-08-09 07:20:56

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,844

Re: Towards a unified and simple indoor mapping scheme

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

Last edited by SimonPoole (2014-08-09 08:31:49)

Offline

#28 2014-08-09 08:07:22

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,844

Re: Towards a unified and simple indoor mapping scheme

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

Offline

#29 2014-09-20 10:53:23

Peda
Member
Registered: 2011-12-29
Posts: 134

Re: Towards a unified and simple indoor mapping scheme

We've further worked hard on this proposal. It can now be found here: https://wiki.openstreetmap.org/wiki/Sim … or_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.

Last edited by Peda (2014-09-20 11:10:25)

Offline

#30 2014-10-02 19:24:31

HolgerJeromin
Member
Registered: 2011-05-25
Posts: 25

Re: Towards a unified and simple indoor mapping scheme

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!

Last edited by HolgerJeromin (2014-10-02 19:29:35)

Offline

#31 2014-12-01 23:50:41

Domiss
Member
Registered: 2013-08-07
Posts: 654

Re: Towards a unified and simple indoor mapping scheme

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.8648 … 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) wink.

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 wink. 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).

Offline

#32 2014-12-02 09:18:43

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,432
Website

Re: Towards a unified and simple indoor mapping scheme

Domiss wrote:

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) wink.

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.

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).

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?

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 wink. That way it is possible to see the real shape of inside part of each room.

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.

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.

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.

Offline

#33 2014-12-02 10:24:52

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: Towards a unified and simple indoor mapping scheme

Tordanik wrote:

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.

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.

Offline

#34 2014-12-03 07:50:10

Domiss
Member
Registered: 2013-08-07
Posts: 654

Re: Towards a unified and simple indoor mapping scheme

Tordanik wrote:

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.

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.

Tordanik wrote:

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?

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...

Tordanik wrote:

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.

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.

Tordanik wrote:

And ultimately, relations are simply not necessary for indoor mapping most buildings in my opinion, so we can avoid the whole issue.

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

BTW Thank you for your answer.

Offline

#35 2014-12-03 11:03:01

HolgerJeromin
Member
Registered: 2011-05-25
Posts: 25

Re: Towards a unified and simple indoor mapping scheme

1) indoor-only POIs. I don't think there should be so many toilet icons on the main maps

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. :-)

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").

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.

Offline

#36 2015-10-16 09:31:23

deuteros76
Member
From: Alzira, Spain
Registered: 2015-08-03
Posts: 8
Website

Re: Towards a unified and simple indoor mapping scheme

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_ … 14_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
- Requires additional drawing
- Less complexity
- The ways are rendered in OSM causing a visualization problem: http://www.openstreetmap.org/#map=19/40.53837/-3.89323

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

Regards

Offline

#37 2015-10-16 09:55:26

saerdnaer
Member
Registered: 2011-12-04
Posts: 38

Re: Towards a unified and simple indoor mapping scheme

There are prototype implementations for routing over areas. Have a look at https://translate.google.de/translate?s … 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

Last edited by saerdnaer (2015-10-16 09:58:22)

Offline

#38 2016-10-31 13:25:59

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,844

Re: Towards a unified and simple indoor mapping scheme

deuteros76 wrote:

....
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
...

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

Offline

Board footer

Powered by FluxBB