[OSM-dev] Towards a unified and simple indoor mapping scheme

[Christopher Baines]

On 20/06/14 10:07, Simon Poole wrote:
> In the aftermath of some discussion at SOTM-EU (see the presentation by
> Thomas Graichen), I've jotted down some of my thoughts on the subject
> here http://forum.openstreetmap.org/viewtopic.php?id=25961
> 
> IMHO the most important thing (besides getting rid of the conflicts) is
> to enable the typical OSM progression in mapping from rough to more
> detailed to insane :-).

Firstly, would you like discussion on this to be on the discussion page
on the wiki, the forum post, on this mailing list, or somewhere else?

Regarding the proposal, thanks for putting it up, I have been mapping
using something similar to the IndoorOSM proposal, but adjusting it
where I needed to.

Some changes that I have been using:

Ignore the ground_level restriction. I tried doing this initially, but
when mapping a building with 4 levels, each of which has entrances from
outside (at that level), and for which the main entrance is on the top
level, I could not see any benefit with this restriction.

Make the entrances/exits members of the relevant level relation, not the
building relation. This includes the level information for the
entrance/exit, whereas having it being a member of the building relation
does not.

Currently for mapping the lifts/stairs I have been using a area
(circular way), tagged with buildingpart:verticalpassage. To represent
which levels this allows access to, it is included as a member of the
associated level relation. Note that so far I have just been using this
data for display purposes, and currently it is not expressive enough to
say that, for example, there is a lift shaft here, but the lift does not
stop on level 3. The role on the level relation could be possibly used
in cases like this?

Some issues that I have encountered:

Could a way be used to represent an entrance to a building which has a
width? This would be useful where you have two buildings that join,
connected with a large (in width) corridor/space. Putting a node
somewhere in the middle of the divide seems a bit broken.

Mapping an outdoor area on the roof of a building is a bit undefined.
You could put the bits in the relevant level relation, but by also
including the shell, you would be able to determine what bits are outdoors.

What is the intention behind shells for levels? I have not really found
a use for them yet. If the building level has a hole in the middle,
should the shell be no different, or should a multipolygon relation be
used instead?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20140620/bfd3ad84/attachment.pgp>