[OSM-talk-be] Nodes or areas to tag amenities
Ubipo .
ubipo.skippy at gmail.com
Wed Apr 18 10:43:05 UTC 2018
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 <marc_marc_irc at hotmail.com> 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 <marc.gemis at gmail.com>
> 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 . <ubipo.skippy at gmail.com>
> 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
> >>> Talk-be at openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>>
> >
> > _______________________________________________
> > Talk-be mailing list
> > Talk-be at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20180418/d3efce09/attachment.htm>
More information about the Talk-be
mailing list