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.
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.
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.
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).
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
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).
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) ;).
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).
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ā).
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?).
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?
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.
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.
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.
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.
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.