<div dir="ltr"><div class="gmail_default" style="font-size:small">After furter consideration I think indoor=level combined with amenity=restaurant should solve most problems.</div><div class="gmail_default" style="font-size:small">Improving the map would then be as simple as not editing the general indoor=level and just drawing new ways for individual rooms (not tagged amenity=restaurant).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A restaurant on multiple floors would indeed be tricky as indoor=level implies a single level, although I think just adding level=0;1 shouldn't be that bad, right?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 April 2018 at 13:58, Marc Gemis <span dir="ltr"><<a href="mailto:marc.gemis@gmail.com" target="_blank">marc.gemis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">how does someone "improve" your mapping to add a separate area for<br>
room=toilets ? nested room areas ? split it off ?<br>
<span class="HOEnZb"><font color="#888888"><br>
m.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 18, 2018 at 12:43 PM, Ubipo . <<a href="mailto:ubipo.skippy@gmail.com">ubipo.skippy@gmail.com</a>> wrote:<br>
> Regarding the housenumbers: street and number is as said probably not needed<br>
> and better reserved for the actual building, although a specialised<br>
> addr:addition=a could be useful for the rooms.<br>
> Regarding room=restaurant, I think that tag is perfectly fine. It just<br>
> indicates the restaurant in it's entirety, with dining room, kitchen etc.<br>
><br>
> On Wed, Apr 18, 2018, 12:10 marc marc <<a href="mailto:marc_marc_irc@hotmail.com">marc_marc_irc@hotmail.com</a>> wrote:<br>
>><br>
>> for the addr : it look like strange that the room is in a building that<br>
>> doesn't have the same addr:housenumber as the building.<br>
>><br>
>> for multiple floors poi, you can draw all room with level=* tag<br>
>> or as a first step only use indoor=yes for the whole area<br>
>><br>
>> room=restaurant look like also strange for me.<br>
>> a restaurant is several room=* item : kitchen, dining room, toilets,<br>
>> cloakroom<br>
>> so what's a room=restaurant ? it can not be the same as the area used<br>
>> for amenity=restaurant. maybe it should be the area for the dining room.<br>
>> the wiki advice to put both tag to the same polygon look like wrong.<br>
>><br>
>><br>
>> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :<br>
>> > o, I forgot, what about a restaurant that occupies multiple floors ?<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis <<a href="mailto:marc.gemis@gmail.com">marc.gemis@gmail.com</a>><br>
>> > wrote:<br>
>> >> The idea of using indoor mapping is good, and it's probably the future<br>
>> >> to solve all the problems you mention. (we had a similar discussion<br>
>> >> last Friday on the Riot channel)<br>
>> >><br>
>> >> Some remarks:<br>
>> >><br>
>> >> - does it make sense for a "room" to have an house number and a street<br>
>> >> ? I would expect those on the building, and floor or level or so on<br>
>> >> the room.<br>
>> >> - I'm not familiar enough with the simple indoor tagging, but I would<br>
>> >> expect that a restaurant exists of multiple rooms (dining, toilets,<br>
>> >> kitchen) not just one.<br>
>> >> - On the Riot channel the entrance to the restaurant was also seen as<br>
>> >> important.<br>
>> >><br>
>> >> m<br>
>> >><br>
>> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . <<a href="mailto:ubipo.skippy@gmail.com">ubipo.skippy@gmail.com</a>><br>
>> >> wrote:<br>
>> >>> Everyone,<br>
>> >>><br>
>> >>> A long standing question for osm mapping in cities is wether to tag<br>
>> >>> amenities in multi-purpose buildings as:<br>
>> >>> - a separate node inside the building's way<br>
>> >>> - the building itself, using both building=house and amenity=* (only<br>
>> >>> valid<br>
>> >>> with single-amenity buildings)<br>
>> >>> The node approach has consistency issues like these buildings:<br>
>> >>> <a href="https://www.openstreetmap.org/node/656793551" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>node/656793551</a> .<br>
>> >>><br>
>> >>> The area approach is more consistent but doesn't really allow<br>
>> >>> multi-purpose<br>
>> >>> buildings.<br>
>> >>> A third, lesser used method is to use part of the simple indoor<br>
>> >>> tagging<br>
>> >>> schema. I've used a simplified version of this for this restaurant:<br>
>> >>> <a href="https://www.openstreetmap.org/way/580985564" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>way/580985564</a> .<br>
>> >>> This approach uses two overlapping ways, one for the general building<br>
>> >>> (tagged building=house) and one for the restaurant on the ground floor<br>
>> >>> (tagged room=restaurant and of course amenity=restaurant).<br>
>> >>><br>
>> >>> Drawbacks of this are for one that the two ways fully overlap. This<br>
>> >>> triggers<br>
>> >>> the JOSM validator and probably some QC tools. Secondly renderers<br>
>> >>> might have<br>
>> >>> trouble placing the icons and house numbers of multiple areas like<br>
>> >>> this.<br>
>> >>> Luckily both these problems could be fixed. The positives are of<br>
>> >>> course:<br>
>> >>> consistency and the possibility for multiple amenities (using the<br>
>> >>> level=*<br>
>> >>> key).<br>
>> >>><br>
>> >>> What do you all think of this approach?<br>
>> >>><br>
>> >>> Kind regards,<br>
>> >>> Pieter (Ubipo)<br>
>> >>><br>
>> >>> ______________________________<wbr>_________________<br>
>> >>> Talk-be mailing list<br>
>> >>> <a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
>> >>> <a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
>> >>><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Talk-be mailing list<br>
>> > <a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
>> > <a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
>> ><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Talk-be mailing list<br>
>> <a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Talk-be mailing list<br>
> <a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
</div></div></blockquote></div><br></div>