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

[Santens Seppe]

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).
 But as others point out, this method will probably not always work.

Seppe

Van: joost schouppe [mailto:joost.schou...@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 . 
>:
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 
> 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 . 
> 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 
> > 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 
>> > >
>> > 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 . 
>> >> >
>> >> 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 

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

[Ubipo .]

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  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=3.732321=19=0=0=1=0=0=0=0=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  > >:
> >
> > 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 .  > >:
> >
> > 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  > > 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 .
> > >
> 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
> >  > > 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
> >  >>
> >  >> 

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

[marc marc]

@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 
> ,
>  
> 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  >:
> 
> 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 .  >:
> 
> 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  > 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 .
> > 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
>  > 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
> >
>  >> > wrote:
>  >> >> The idea of using 

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

[Pieter Vander Vennet]

I have some experience with indoor mapping.

I would invite you guys to have a look at my work of the Blekerij in Gent
,
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 :

> 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 . :
>
>> 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  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 . 
>>> 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 
>>> 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 
>>> >> > 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 . 
>>> >> >> 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 

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

[joost schouppe]

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 . :

> 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  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 .  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 
>> 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 
>> >> > 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 . 
>> >> >> 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@openstreetmap.org
>> >> >>> 

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

[Ubipo .]

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  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 .  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  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 
> >> > 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 . 
> >> >> 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@openstreetmap.org
> >> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >> >>>
> >> >
> >> > ___
> >> > Talk-be mailing list
> >> > Talk-be@openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/talk-be
> >> >
> >>
> >> ___
> >> Talk-be mailing list
> >> 

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

[Marc Gemis]

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 .  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  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 
>> > 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 . 
>> >> 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@openstreetmap.org
>> >>> https://lists.openstreetmap.org/listinfo/talk-be
>> >>>
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Ubipo .]

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  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 
> 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 . 
> 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@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>>
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[marc marc]

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  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 .  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@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Marc Gemis]

o, I forgot, what about a restaurant that occupies multiple floors ?



On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis  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 .  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@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Marc Gemis]

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 .  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Ubipo .]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be