[OSM-talk-be] Nodes or areas to tag amenities

Thu Apr 19 07:25:18 UTC 2018

For this particular example, I thought it was quite appropriate. The different shops are in the same building (according to GRB), but can also be clearly separated ‘architecturally’ (see streetview<https://www.google.be/maps/@51.0899216,3.4454343,3a,75y,37.39h,83.82t/data=!3m7!1e1!3m5!1sx4e3GkQ16irl8xvamEQedw!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3Dx4e3GkQ16irl8xvamEQedw%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D9.20368%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656?hl=nl>). But as others point out, this method will probably not always work.

Seppe

Van: joost schouppe [mailto:joost.schouppe at gmail.com]
Verzonden: woensdag 18 april 2018 18:15
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] Nodes or areas to tag amenities

How does this relate to the building:part=yes strategy that L'imaginaire has been playing with, e.g. https://www.openstreetmap.org/way/283645760

2018-04-18 15:56 GMT+02:00 Ubipo . <ubipo.skippy at gmail.com<mailto:ubipo.skippy at gmail.com>>:
After furter consideration I think indoor=level combined with amenity=restaurant should solve most problems.
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).

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?

On 18 April 2018 at 13:58, Marc Gemis <marc.gemis at gmail.com<mailto:marc.gemis at gmail.com>> wrote:
how does someone "improve" your mapping to add a separate area for
room=toilets ? nested room areas ? split it off ?

m.

On Wed, Apr 18, 2018 at 12:43 PM, Ubipo . <ubipo.skippy at gmail.com<mailto:ubipo.skippy at gmail.com>> wrote:
> 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<mailto: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<mailto: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<mailto: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<mailto:Talk-be at openstreetmap.org>
>> >>> https://lists.openstreetmap.org/listinfo/talk-be
>> >>>
>> >
>> > _______________________________________________
>> > Talk-be mailing list
>> > Talk-be at openstreetmap.org<mailto:Talk-be at openstreetmap.org>
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org<mailto:Talk-be at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org<mailto:Talk-be at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-be
>

_______________________________________________
Talk-be mailing list
Talk-be at openstreetmap.org<mailto:Talk-be at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be

_______________________________________________
Talk-be mailing list
Talk-be at openstreetmap.org<mailto:Talk-be at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be

--
Joost Schouppe
OpenStreetMap<http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter<https://twitter.com/joostjakob> | LinkedIn<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20180419/ec8beac1/attachment.htm>