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