[OSM-talk] Door to door routing to buildings with multiple occupants

[Rob Nickerson]

Thanks for your reply Martin,

I was aware of key:entrance but building:part was new to me so thanks for
letting me know about that one. In regards to the following, can you please
explain a little more about _how_ to map these. For example, I understand
1a but what nodes/ways/closed ways are you suggesting tagging in 1b and 2a?

1a) a node for the shop floating inside the building
1b) like 1a but part of the outline
2a) a multipolygon with the building as outer
2b) an explicit polygon overlapping with the building

Sounds like a building with 2 shops would best be mapped as 3 closed ways -
1 for the building, and 2 inside the building that give the position of the
shop and are tagged with amenity=*, name=*, addr (and optionaly
building:part=yes). These 2 inner closed ways are likely to share
boundaries with the builiding closed way and with each other. Would you
tend to agree?

Regards,
Rob




On 30 November 2012 02:23, Martin Koppenhoefer <dieterdreist at gmail.com>wrote:

> 2012/11/29 Rob Nickerson <rob.j.nickerson at gmail.com>:
> > Where should amenity=* and addr:*=* be tagged? One suggestion was to add
> all
> > the detail to the entrance node, but this seems odd to me. For single
> > occupancy buildings I suggested tagging the building as amenity=*, etc as
> > the entrance node on the building can be easily matched with these.
>
>
> it is better to distinguish the building from the occupancy to avoid
> confusions to which entity the tags belong. There can be ambiguity
> e.g. in name, operator, start_date, description, wikipedia, and
> others. You can overcome this by splitting them into logic entities.
>
> If you say that the building is a polygon (or mp relation), we get
> basically these options for the "shop":
> 1a) a node for the shop floating inside the building
> 1b) like 1a but part of the outline
> 2a) a multipolygon with the building as outer
> 2b) an explicit polygon overlapping with the building
> 3) a relation that somehow says what is in this building
>
> current consense seems to be 1a) 2a) and 2b) but some people also do 1b)
>
> 1b) has the disadvantage that the shop is inside the building but with
> this way of mapping it is in between outdoors and inside.
>
> a shop has always some extent, so I'd consider 1a) preliminary (it
> would be better to have the area to see how big it is etc.)
>
> 2a) doesn't duplicate geometry but it might break often (due to
> missing editor support in some editors)
>
> 2b) creates redundant geometry (overlapping way)
>
> 3) either doesn't tell you much about the extent or it will be very
> similar to 2a,  and their might be other problems as well (e.g. also
> missing editor support at the moment)
>
>
> > But what about a building with multiple occupants and entrances. For
> example
> > 2 shops in one building.
>
>
> entrances can be mapped with the key "entrance"
> http://wiki.openstreetmap.org/wiki/Key:entrance
>
>
> > One option is to tag the building with building=yes
> > and then add the amenity tags to individual nodes, but then how would
> door
> > to door routing work?
>
>
> first you'd need to make sure the doors are mapped ;-)
>
>
> > An alternative is to just split the building in to 2
> > areas (but technically its 1 building). Can we use some form of indoor
> > mapping (e.g. room=yes, amenity=*)?
>
>
> there is building:part (for parts of a building obviously), but also
> with one big building there is no problem with putting several
> amenity-polygons inside. If there is 1 building in the real world we
> should also have one object in OSM which says "this is one building"
> (i.e. a polygon or multipolygon with building=*), so bascially you
> would need 3 polygons to map a building with 2 POIs in it.
>
> You don't need a room-concept to map the extent of a POI, but there is one
> ;-)
> http://wiki.openstreetmap.org/wiki/Proposed_features/indoor
>
> cheers,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20121130/7265088e/attachment-0001.html>