[OSM-talk-be] Nodes or areas to tag amenities
Ubipo .
ubipo.skippy at gmail.com
Wed Apr 18 18:37:16 UTC 2018
I agree on the separation of building:part=* for architectural distinct
building parts and room=* for mostly functionaly distinct parts of a
building. I think there should be a general indoor=part or something (don't
quote me on that tag, I can't really think of something better). This would
then replace the room=restaurant and would serve to separate functionaly
different parts of a building. Another example apart from a restaurant is a
building containing both classrooms and a library. The library would be
tagged as indoor=part and the relevant amenity (with optional room=*'s
inside that) and the classrooms would just be tagged as room=* and
indoor=room as they don't really form a whole.
On Wed, Apr 18, 2018, 18:54 marc marc <marc_marc_irc at hotmail.com> wrote:
> @ubipo for indoor=level, I suppose you mean indoor=yes indoor=thenumber :)
>
> building:part is for a part of a building where tag related to the
> building itself doesn't have the same value for one part <> another part
> for exemple a building that have one part with one level :
> building:part=yes
> building:levels=1
> and another part with 2 levels
> building:part=yes
> building:levels=1
> both parts make one building with building=yes on the outline
>
> but inside a buidling, room nearly never affect the building "external
> look"
> so it should not be any building:part tag on a room,
> except if a building:part is made by only one room of course.
>
> for room=restaurant on amenety=restaurant, I've been talking with
> PanierAvide who add this to the wiki. he agree that this is not good.
> we are working on on howto make it better.
>
> Le 18. 04. 18 à 18:43, Pieter Vander Vennet a écrit :
> > I have some experience with indoor mapping.
> >
> > I would invite you guys to have a look at my work of the Blekerij in
> > Gent
> > <
> https://openlevelup.net/old/?lat=51.060092&lon=3.732321&z=19&t=0&lvl=0&tcd=1&urd=0&bdg=0&pic=0&nte=0&ilv=0>,
>
> > as example. Toilets can be mapped as either a point or area with
> > 'amenity=toilets, indoor=yes; level=0' (or perhaps 'level=0-2', e.g. for
> > a building with toilets on the same location on floors 0 till 2.). Note
> > that 'level=0' is the ground floor (gelijkvloers).
> >
> > I have no experience with the building:part=yes. I assume that
> > indoor=yes implies 'building:part=yes' and that 'building:part' is
> > rather used for roofs etc...
> >
> >
> >
> >
> > Met vriendelijke groeten,
> > Pieter Vander Vennet
> >
> > 2018-04-18 18:13 GMT+02:00 joost schouppe <joost.schouppe at gmail.com
> > <mailto:joost.schouppe at gmail.com>>:
> >
> > 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
> > <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
> > <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
> > <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
> > <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
> > <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
> > <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
> > <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
> > <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
> > <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/>
> >
> > _______________________________________________
> > Talk-be mailing list
> > Talk-be at openstreetmap.org <mailto:Talk-be at openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-be
> > <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/acea661c/attachment.htm>
More information about the Talk-be
mailing list