Regarding the housenumbers: street and number is as said probably not needed and better reserved for the actual building, although a specialised addr:addition=a could be useful for the rooms. Regarding room=restaurant, I think that tag is perfectly fine. It just indicates the restaurant in it's entirety, with dining room, kitchen etc.
On Wed, Apr 18, 2018, 12:10 marc marc <[email protected]> wrote: > for the addr : it look like strange that the room is in a building that > doesn't have the same addr:housenumber as the building. > > for multiple floors poi, you can draw all room with level=* tag > or as a first step only use indoor=yes for the whole area > > room=restaurant look like also strange for me. > a restaurant is several room=* item : kitchen, dining room, toilets, > cloakroom > so what's a room=restaurant ? it can not be the same as the area used > for amenity=restaurant. maybe it should be the area for the dining room. > the wiki advice to put both tag to the same polygon look like wrong. > > > Le 18. 04. 18 à 11:56, Marc Gemis a écrit : > > o, I forgot, what about a restaurant that occupies multiple floors ? > > > > > > > > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis <[email protected]> > wrote: > >> The idea of using indoor mapping is good, and it's probably the future > >> to solve all the problems you mention. (we had a similar discussion > >> last Friday on the Riot channel) > >> > >> Some remarks: > >> > >> - does it make sense for a "room" to have an house number and a street > >> ? I would expect those on the building, and floor or level or so on > >> the room. > >> - I'm not familiar enough with the simple indoor tagging, but I would > >> expect that a restaurant exists of multiple rooms (dining, toilets, > >> kitchen) not just one. > >> - On the Riot channel the entrance to the restaurant was also seen as > important. > >> > >> m > >> > >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . <[email protected]> > wrote: > >>> Everyone, > >>> > >>> A long standing question for osm mapping in cities is wether to tag > >>> amenities in multi-purpose buildings as: > >>> - a separate node inside the building's way > >>> - the building itself, using both building=house and amenity=* (only > valid > >>> with single-amenity buildings) > >>> The node approach has consistency issues like these buildings: > >>> https://www.openstreetmap.org/node/656793551 . > >>> > >>> The area approach is more consistent but doesn't really allow > multi-purpose > >>> buildings. > >>> A third, lesser used method is to use part of the simple indoor tagging > >>> schema. I've used a simplified version of this for this restaurant: > >>> https://www.openstreetmap.org/way/580985564 . > >>> This approach uses two overlapping ways, one for the general building > >>> (tagged building=house) and one for the restaurant on the ground floor > >>> (tagged room=restaurant and of course amenity=restaurant). > >>> > >>> Drawbacks of this are for one that the two ways fully overlap. This > triggers > >>> the JOSM validator and probably some QC tools. Secondly renderers > might have > >>> trouble placing the icons and house numbers of multiple areas like > this. > >>> Luckily both these problems could be fixed. The positives are of > course: > >>> consistency and the possibility for multiple amenities (using the > level=* > >>> key). > >>> > >>> What do you all think of this approach? > >>> > >>> Kind regards, > >>> Pieter (Ubipo) > >>> > >>> _______________________________________________ > >>> Talk-be mailing list > >>> [email protected] > >>> https://lists.openstreetmap.org/listinfo/talk-be > >>> > > > > _______________________________________________ > > Talk-be mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/talk-be > > > > _______________________________________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
