Re: [OSM-talk-be] Nodes or areas to tag amenities
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_...@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=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 <joost.schou...@gmail.com > > <mailto:joost.schou...@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.ski...@gmail.com > > <mailto:ubipo.ski...@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.ge...@gmail.com > > <mailto:marc.ge...@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.ski...@gmail.com <mailto:ubipo.ski...@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. > > > >
Re: [OSM-talk-be] Nodes or areas to tag amenities
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.ge...@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.ski...@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_...@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.ge...@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.ski...@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
Re: [OSM-talk-be] Nodes or areas to tag amenities
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_...@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.ge...@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.ski...@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@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
[OSM-talk-be] Nodes or areas to tag amenities
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
Re: [OSM-talk-be] Belgium Phone Format OSM Tool
Hi, I must have misread that somewhere then... The demo at http://rawgit.com/googlei18n/libphonenumber/master/javascript/i18n/phonenumbers/demo-compiled.html seems to indeed work for all Belgian area codes. I'll port my tool over to instead use that library and try to make it international. Best, Ubipo ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Belgium Phone Format OSM Tool
Hey all, Haha thanks for noticing that rookie mistake Wouter, better now than when I implement it I guess... I added some automated tests to check for basic errors like that one to the repo on GitHub. Regarding that JOSM thread, It would be awesome if JOSM had a build-in validator/normalizer/formatter. Although it could prove difficult if you also want to format the area code and subscriber number. Just look all the hoops I had to jump through to get Belgian numbers working. I don't know of any library that does all that :( Anyway, if anybody knows how to PUT a task status on maproulette, do let me know. Best, Ubipo ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Belgium Phone Format OSM Tool
Hey all, I wanted to let you know about a tool I made called 'BPF' - Belgium Phone Formatter. When provided with OSM login credentials and a list of OSM ID's to fix, it scans those objects for 'phone', 'contact:phone', 'fax' and 'contact:fax' tags and attempts to normalize them. If it fails (sees a difficult/unrecognized number), it leaves the whole object unchanged. [image: BPF-Illustration.png] The tool/script is mainly meant to make this MapRoulette challenge <http://maproulette.org/map/2673> a little easier. But if you find another use for it feel free to download and use the python script from https://github.com/Ubipo/BpfOsmTool. The reason that particular MapRoulette challenge isn't fixed already is that: One: I wanted some other people's input about whether this is a good idea. And two: I'm having some problems with the MapRoulette API: Google Doc <https://docs.google.com/document/d/1tUDXGHHQLgL98OwF0JCNMFPSii1Yr7Zkq3k6mF9k4J4/edit?usp=sharing> Best, Ubipo ubipo.ski...@gmail.com <ubipo.ski...@gmail.com?Subject=Regarding%20BpfOsmTool> OSM Profile <http://www.openstreetmap.org/user/Ubipo> ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
