[Tagging] Feature Proposal - RFC - Reception Desk (mark 2)
Hi, Request for comment/s on the proposed tag amenity=reception_desk. This is the second attempt at this. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk Reception desks can be hard to find, e.g. in multibuilding complexes where only one reception desk occurs. Hotels have them, larger offices have them, they are hand things for visitors to locate. This new proposal has explanations for; Why the amenity key is selected. Why desk appears in the name. How to relate this feature to other objects. How this relates to Indoor Tagging (basicly the same as any other amenity, office, shop tag .. it doesn't .. Indoor Tagging will have to deal with ALL these in the same way). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
2015-03-10 22:41 GMT+01:00 David Bannon dban...@internode.on.net: On Tue, 2015-03-10 at 09:35 -0700, Bryce Nesbitt wrote: The wiki has a very low correlation to the rendering. Does it ? Are you suggesting that there is substantial usage of tags that don't appear on the wiki ? If so, I'd suggest we need to fix the wiki. +1 Rendering is not the only goal of OSM data collection. True, but its still the main goal IMHO. Would you suggest otherwise ? this really depends on the kind of use that you intend. routing and geocoding / search / interactive maps are important goals as well. Many attributes that are very common cannot be displayed in a reasonable way in a rendering, at least not all of them. Think the wikipedia tag for instance. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
2015-03-08 23:08 GMT+01:00 Warin 61sundow...@gmail.com: The way I search for a relevant tag is to use the wiki, not taginfo. I suspect many mappers do the same. I recommend using several sources, my personal priority order is: the wiki, taginfo, mailing lists. Using a tag that is not on the wiki will probably mean it is not rendered. rendered where? Many if not even most of the tags that are described in the wiki are actually not rendered on the OSM-Carto style. . thus I may have wasted my effort. -1, there are lots of other uses for the data besides the one stylesheet that is the first on the list on OSM's homepage. If the tag is interesting for a general purpose map, chances are not bad it'll sooner or later get implemented also in the Carto-OSM stylesheet. If people were only using tags that get rendered right now in this style sheet, there wouldn't be any tagging progress at all (meaning also that a lot of features could not be described at all), and if we would have been working like this 10 years ago, there wouldn't be any map at all now. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
2015-03-08 23:08 GMT+01:00 Warin 61sundow...@gmail.com: The way I search for a relevant tag is to use the wiki, not taginfo. I suspect many mappers do the same. Using a tag that is not on the wiki will probably mean it is not rendered. Many mappers don't use the wiki at all. The wiki has a very low correlation to the rendering. Rendering is not the only goal of OSM data collection. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Tue, 2015-03-10 at 11:38 +0100, Martin Koppenhoefer wrote: .. Using a tag that is not on the wiki will probably mean it is not rendered. rendered where? Many if not even most of the tags that are described in the wiki are actually not rendered on the OSM-Carto style. While true Martin, its a simplification. A tag mentioned in the wiki or other authoritative source is seen by many people and therefore more likely to be used in many entries than some tag that I personally think is great but one one else realises I'm using. And anyone making a render decision is likely to consider the number of times a tag is used (among other things). So, the wiki and similar focuses efforts on a smaller set of tags. Have a think about the Tower of Babel. David . thus I may have wasted my effort. -1, there are lots of other uses for the data besides the one stylesheet that is the first on the list on OSM's homepage. If the tag is interesting for a general purpose map, chances are not bad it'll sooner or later get implemented also in the Carto-OSM stylesheet. If people were only using tags that get rendered right now in this style sheet, there wouldn't be any tagging progress at all (meaning also that a lot of features could not be described at all), and if we would have been working like this 10 years ago, there wouldn't be any map at all now. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Tue, 2015-03-10 at 09:35 -0700, Bryce Nesbitt wrote: The wiki has a very low correlation to the rendering. Does it ? Are you suggesting that there is substantial usage of tags that don't appear on the wiki ? If so, I'd suggest we need to fix the wiki. Rendering is not the only goal of OSM data collection. True, but its still the main goal IMHO. Would you suggest otherwise ? David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Sat, Mar 7, 2015 at 4:57 PM, Warin 61sundow...@gmail.com wrote: -- Request For Comments ... I see this as part of improving the proposal .. not as showing a complete, fully functional for all possible things, fault free tag. If only complete fault free and all encompassing tags are to be proposed then there will be NO tags. I think that a proposal made with that goal will face headwinds. A good idea can be poorly presented, and get negative feedback for that reason alone. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
+1 On Sun, Mar 8, 2015, 23:09 Warin 61sundow...@gmail.com wrote: On 9/03/2015 1:22 AM, Andreas Goss wrote: Why do you even bother with a proposal when you bascially don't care about tagging? I care to get good, if not the best, tags. I try to get ideas for these from the tagging group. I don't care for arguments on a proposal that are not directly relevant to that proposal. If you want to tag reception_desks in whatever random way then just go ahead and do it. I don't want a random way .. thank you for the derogatory comment. Then people will see what you used on taginfo when looking for reception and at some point you just make a wiki page with in use. You really don't care for the tagging group much, do you? The way I search for a relevant tag is to use the wiki, not taginfo. I suspect many mappers do the same. Using a tag that is not on the wiki will probably mean it is not rendered.. thus I may have wasted my effort. By waving the flag for this possibly new tag, the tag gets improved by thoughtfull comments, advertised, and hopefully approved. -- Request For Comments ... I see this as part of improving the proposal .. not as showing a complete, fully functional for all possible things, fault free tag. If only complete fault free and all encompassing tags are to be proposed then there will be NO tags. By all means comment on things that could be better ... and hopefully suggest possible solutions. Don't think a proposal should have addressed all possible things.. if they could see the world and all its problems, and then solve them in the bast possible way .. well OSM would not need proposals .. they would simply go straight to tags! And there would be no need of the tagging group. Criticism that a proposal is incomplete, should have address some issue .. before being proposed .. will simply discourage people from using the tagging group at all and going straight to make a tag without consultation .. leading to a worse situation. People here need to encourage proposals .. no matter how poor they might think them to be, to do otherwise is to discourage the use of this group. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 9/03/2015 1:22 AM, Andreas Goss wrote: Why do you even bother with a proposal when you bascially don't care about tagging? I care to get good, if not the best, tags. I try to get ideas for these from the tagging group. I don't care for arguments on a proposal that are not directly relevant to that proposal. If you want to tag reception_desks in whatever random way then just go ahead and do it. I don't want a random way .. thank you for the derogatory comment. Then people will see what you used on taginfo when looking for reception and at some point you just make a wiki page with in use. You really don't care for the tagging group much, do you? The way I search for a relevant tag is to use the wiki, not taginfo. I suspect many mappers do the same. Using a tag that is not on the wiki will probably mean it is not rendered.. thus I may have wasted my effort. By waving the flag for this possibly new tag, the tag gets improved by thoughtfull comments, advertised, and hopefully approved. -- Request For Comments ... I see this as part of improving the proposal .. not as showing a complete, fully functional for all possible things, fault free tag. If only complete fault free and all encompassing tags are to be proposed then there will be NO tags. By all means comment on things that could be better ... and hopefully suggest possible solutions. Don't think a proposal should have addressed all possible things.. if they could see the world and all its problems, and then solve them in the bast possible way .. well OSM would not need proposals .. they would simply go straight to tags! And there would be no need of the tagging group. Criticism that a proposal is incomplete, should have address some issue .. before being proposed .. will simply discourage people from using the tagging group at all and going straight to make a tag without consultation .. leading to a worse situation. People here need to encourage proposals .. no matter how poor they might think them to be, to do otherwise is to discourage the use of this group. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Am 08.03.2015 um 00:51 schrieb Andreas Goss andi...@t-online.de: It should be found because OSM is a geographical database and the reception, or the multiple receptions as you asked before, is/are contained in the campus of the facility. So bascially most of the time you would just tag amenity=reception_desk without any other tags and that's enough? for a lot of cases this will indeed be sufficient. If you can't resolve the issue spatially you could use the site relation Apart from that you are ignoring buildings with multiple companies and different reception desks, could in many cases be solved spatially as well (by looking at the enclosing office / shop etc. polygons and their building level, in case you are still using nodes for these I'd suggest when you get to do micro mapping at the reception desk level you'd better have them converted to areas) Also I believe most of the time you'll be more interested in the entrance, the reception desk will very likely be close to it. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Also I believe most of the time you'll be more interested in the entrance, the reception desk will very likely be close to it. On our campus, we have a couple of dozens of entrances for employees but only three of four receptions where a non-employee can enter. So mapping a reception definitely provides added value. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
You really don't care for the tagging group much, do you? The way I search for a relevant tag is to use the wiki, not taginfo. I suspect many mappers do the same. Using a tag that is not on the wiki will probably mean it is not rendered.. thus I may have wasted my effort. By waving the flag for this possibly new tag, the tag gets improved by thoughtfull comments, advertised, and hopefully approved. +1 I only found out about taginfo from looking through the wiki. The approved tag set helped a lot when learning to tag and when tagging new features, and many key and value pages explain the tagging in a way that taginfo certainly can’t... Also, the presets in the renderer help a lot to discover tags, as they let you search for “real world” terms that translate into a tag or set of tags (sidewalk comes to mind). However, when looking for certain features searching the wiki is very confusing (they should have like a “tag key/value” search or something, or restrict to language). The details for mapping many things is in the value’s wiki page, which is hidden behind the key features, hidden behind “map features” - which obscures so many useful values. since the search is so dependent on the value, I have to know exactly what I’m searching for - it’s difficult to know the exact term OSMers prefer. There should be a “sitemap listing” of key/values - a single page of the keys and all the values mentioned *anywhere on the wiki* for that key - like a white pages - drilling down through the pages is often times not very useful, and “map features” can never be so inclusive. The other major downside to the wiki is the unmanaged graveyard of abandoned proposals. when I saw the proposals or pending proposals or something page, the list is miles long, some from 2008. it should be pruned to 6 months or 1 year, and moved to abandoned or something - otherwise I het my hopes up when searching for a feature, only to find it was suggested and effectively abandoned in 2009 - which means I don’t have much of a chance getting it approved (IMO). Looking at taginfo lets one see what is currently in OSM, and even though there is a lot of chaff, it is is the easiest way to find the “wheat” of a tag - but that is useful for then documenting it for others to easily find and understand on the wiki. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Why do you even bother with a proposal when you bascially don't care about tagging? If you want to tag reception_desks in whatever random way then just go ahead and do it. Then people will see what you used on taginfo when looking for reception and at some point you just make a wiki page with in use. And I don't think there are that many options that you would not be able to cover the majority of them. - A single facility covers whole area and has one or multiple receptions - Companies have different receptions in the same building - Multiple companies use the same reception in one building -(Reception outside building/facility area) That probably covers 99% On 3/8/15 01:57 , Warin wrote: On 8/03/2015 10:22 AM, Andreas Goss wrote: Do you 'navigate' to 'drinking water' or simply look for the closest one? Depends if I said I will meet someone at drinking water spot xyz or I'm just looking for some water. most would navigate to an address .. then look on the map for parking, then look on the map for the closest reception desk So that's the _quality_ of data you are fine with in OSM? Why do we even tag house numbers then? Finding the right street and then looking at the numbers is even easier than this, don't even have to get out of the car. Small point ... The data may be correct and of high quality .. but missing what you want .. thus lacking detail, resolution or quantity ... not quality. Lacking quality would be, say, if the node were displaced .. say 2 kms. Or if the name was wrong. Most of 'my' local area has no OSM house numbers .. nor are residential buildings mapped, there are a few missing street names too. The level of data resolution and quantity is up to the contributors, their time and inclination. Before I map house numbers .. I think the missing street names should be done? You may think that address numbers are more important than reception desks ..I don't, simply for the reason you have given above looking at the numbers is even easier than finding a reception desk in a facility .. particularly when a multi building facility. A name of the reception desk would help ... but some of them are for all the firms in that location. Then why isn't this addressed at all in the proposal? There are many possibilities. Covering them all? I'd rather leave the variations up to the mapper .. they are inventive and are on the ground so know the situation better than I could possibly imagine it. The ones I know of are simple .. at least I see it that way. What you have I don't know and won't try to predict what the best possible solution is for something I can only guess at... Sorry but my crystal ball is broken. If there were a set preference that covers all (or at least most) cases then state it .. I've got no firm idea of what solution that is. - This is ONE case that I know very well. A group of buildings - all on one site. One major firm owns the site... but leases parts off to other firms .. One reception desks for all. One address for all (yes all the buildings have one address). The reception desk is poorly marked .. has been for many decades. Not uncommon to find visitors wandering around lost. == thus the reception desks exist in an area with one address, so one address. I'd not name it .. the firms change over time , but the reception desk remains. Possibly name the operator as the site owner. But I'd leave the name off. - Relations which could handle this are not mentioned once. First time that has been mentioned. I've not though of it. I'd see that as another proposal ... First get a tag for 'reception desk' .. whatever it is called and where ever it is placed on the OSM data base. Then see if a relationship is needed .. and if that relationship may be used on other features too. Like 'my' proposed relationship for area- steps? And again how would you name it if it was just one of multiple recpetions desks for one facility. Facility name = operator=* name=Gate 1? So if the reception has no name then name= stays empty? Do I use the plant name as operator? Or the company name? Is it possible to put that in operator or official_name, or is the name assumed because the point is inside the landuse? The basic answer would be .. how do the people there name the desks? Use that - the locals will understand it, visitors may be given that name too. See the wiki - http://wiki.openstreetmap.org/wiki/Key:name The common default name. Multiple reception desks for one facility? Do they have separate functions? Or the same functions in different locations? I'd use a name appropriate to the circumstance! I don't know the circumstance .. so don't know the answer. There are too many possibilities that exist for your given question. -- Request For Comments ... I see this as part of improving the proposal .. not
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 8/03/2015 10:22 AM, Andreas Goss wrote: And again how would you name it if it was just one of multiple recpetions desks for one facility. Facility name = operator=* name=Gate 1? So if the reception has no name then name= stays empty? Do I use the plant name as operator? Or the company name? In summary .. how to use the name= tag is defined by the name= wiki .. and should not be redefined by this proposal. --- Detail Is it up to the reception_desk tag to say how to use the name= tag? The name tag should say how to use it .. and it does... The common default name. Thinking on it more .. it should be the name given to a visitor by the firm to say where to go, that would be may preference on how to use the name tag. If the reception desks are all the same then there is no point in trying to isolate an individual one by name .. that is done by the location. If they have separate function/s then surely that would be indicated by the name? Hypothetically a conundrum can be posed that has no solution .. but in practice people will overcome impracticalities by naming them differently even if officially they have the same name. And yes .. if it has no name then don't use the name tag .. same as some roads around here .. they have no name .. and someone has put name=no name on them ... if it has no name don't use the name= tag.. simple? Yes? For operator look at the operator tag ... http://wiki.openstreetmap.org/wiki/Key:operator that also references owner and ownership... and questions on those tag should be answered by looking at the wiki pages on them .. not posing as problems of the reception_desk tag? Who do you put on the building as the operator .. the plant name or the company name ... should be answered on the operator wiki not the building wiki nor the reception desk proposal... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Well, I think it depends on what kind of visitor you are. For the plant tour there is probably just one meeting and entrance point. But for suppliers, constuction workers, people from the same company who don't work at that plant I don't think it matters. Then that would be 3 reception desks with 3 different names. And how do I tag them? name= OpenStreetMap Plant Springfield - Gate 1, OpenStreetMap Plant Springfield - Gate 2 etc.? You have visitor reception at all gates? Visitor badging and everything? I assume there is security there letting people in (gate) but are there 3 areas for a person to be badged and wait for their visitee to come down and pick them up? 3 places to sign up for the tour of the facility? 3 places vendors come to register to meet with buyers? Then that would be 3 reception desks with 3 different names. Javbw I approve this proposal. Also very useful for big industrial areas. [...] --Mapper999 (talk) 15:58, 2 March 2015 (UTC) So how do you tag it on a industrial complex when you have it at let's say Gate 1, Gate 2 and Gate 3? https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk#Comments ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
You have visitor reception at all gates? Visitor badging and everything? I assume there is security there letting people in (gate) but are there 3 areas for a person to be badged and wait for their visitee to come down and pick them up? 3 places to sign up for the tour of the facility? 3 places vendors come to register to meet with buyers? Then that would be 3 reception desks with 3 different names. Javbw Sent from my iPhone I approve this proposal. Also very useful for big industrial areas. [...] --Mapper999 (talk) 15:58, 2 March 2015 (UTC) So how do you tag it on a industrial complex when you have it at let's say Gate 1, Gate 2 and Gate 3? https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk#Comments __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I approve this proposal. Also very useful for big industrial areas. [...] --Mapper999 (talk) 15:58, 2 March 2015 (UTC) So how do you tag it on a industrial complex when you have it at let's say Gate 1, Gate 2 and Gate 3? https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk#Comments __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I believe it depends on the facility. My company has 3 receptions, and they are called officially Reception 7, 4 and 8; these are the names appearing on the phone when I receive a call to collect a visitor. I will use that as the names. On Sat, Mar 7, 2015 at 3:57 PM, Andreas Goss andi...@t-online.de wrote: Well, I think it depends on what kind of visitor you are. For the plant tour there is probably just one meeting and entrance point. But for suppliers, constuction workers, people from the same company who don't work at that plant I don't think it matters. Then that would be 3 reception desks with 3 different names. And how do I tag them? name= OpenStreetMap Plant Springfield - Gate 1, OpenStreetMap Plant Springfield - Gate 2 etc.? You have visitor reception at all gates? Visitor badging and everything? I assume there is security there letting people in (gate) but are there 3 areas for a person to be badged and wait for their visitee to come down and pick them up? 3 places to sign up for the tour of the facility? 3 places vendors come to register to meet with buyers? Then that would be 3 reception desks with 3 different names. Javbw I approve this proposal. Also very useful for big industrial areas. [...] --Mapper999 (talk) 15:58, 2 March 2015 (UTC) So how do you tag it on a industrial complex when you have it at let's say Gate 1, Gate 2 and Gate 3? https://wiki.openstreetmap.org/wiki/Tag:amenity% 3Dreception_desk#Comments ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Is it possible to put that in operator or official_name, or is the name assumed because the point is inside the landuse? Javbw Sent from my iPhone On Mar 8, 2015, at 7:19 AM, Kotya Karapetyan kotya.li...@gmail.com wrote: On Sat, Mar 7, 2015 at 10:24 PM, Andreas Goss andi...@t-online.de wrote: And if I'm a visitor how would for example a OSM based navigation system figure out to which company or facility they belong? I think it's a relevant point. I would include the company/hospital/university etc. name in the reception name. Similar to how it's done to the building names in our campus: http://osm.org/go/0EujzVLy6?node=2727694798. Then the routing softawre can indeed find the correct way to the needed reception. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
It should be found because OSM is a geographical database and the reception, or the multiple receptions as you asked before, is/are contained in the campus of the facility. So bascially most of the time you would just tag amenity=reception_desk without any other tags and that's enough? Apart from that you are ignoring buildings with multiple companies and different reception desks, which I think I already brought up some weeks ago... __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Sat, Mar 7, 2015 at 10:24 PM, Andreas Goss andi...@t-online.de wrote: And if I'm a visitor how would for example a OSM based navigation system figure out to which company or facility they belong? I think it's a relevant point. I would include the company/hospital/university etc. name in the reception name. Similar to how it's done to the building names in our campus: http://osm.org/go/0EujzVLy6?node=2727694798. Then the routing softawre can indeed find the correct way to the needed reception. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
What information would the visitor have to select the company/facility? The name? The address? If the visitor does not know then they go to the nearest one and ask.. at least the visitor has an indication of where a reception desk is rather than just a collection of buildings/entrances. On 8/03/2015 8:24 AM, Andreas Goss wrote: And if I'm a visitor how would for example a OSM based navigation system figure out to which company or facility they belong? On 3/7/15 22:11 , Kotya Karapetyan wrote: I believe it depends on the facility. My company has 3 receptions, and they are called officially Reception 7, 4 and 8; these are the names appearing on the phone when I receive a call to collect a visitor. I will use that as the names. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Do you 'navigate' to 'drinking water' or simply look for the closest one? Depends if I said I will meet someone at drinking water spot xyz or I'm just looking for some water. most would navigate to an address .. then look on the map for parking, then look on the map for the closest reception desk So that's the quality of data you are fine with in OSM? Why do we even tag house numbers then? Finding the right street and then looking at the numbers is even easier than this, don't even have to get out of the car. A name of the reception desk would help ... but some of them are for all the firms in that location. Then why isn't this addressed at all in the proposal? Relations which could handle this are not mentioned once. And again how would you name it if it was just one of multiple recpetions desks for one facility. Facility name = operator=* name=Gate 1? So if the reception has no name then name= stays empty? Do I use the plant name as operator? Or the company name? Is it possible to put that in operator or official_name, or is the name assumed because the point is inside the landuse? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
And if I'm a visitor how would for example a OSM based navigation system figure out to which company or facility they belong? On 3/7/15 22:11 , Kotya Karapetyan wrote: I believe it depends on the facility. My company has 3 receptions, and they are called officially Reception 7, 4 and 8; these are the names appearing on the phone when I receive a call to collect a visitor. I will use that as the names. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Kotya Karapetyan wrote on 2015-03-07 23:19: On Sat, Mar 7, 2015 at 10:24 PM, Andreas Goss andi...@t-online.de mailto:andi...@t-online.de wrote: And if I'm a visitor how would for example a OSM based navigation system figure out to which company or facility they belong? It should be found because OSM is a geographical database and the reception, or the multiple receptions as you asked before, is/are contained in the campus of the facility. I think it's a relevant point. I would include the company/hospital/university etc. name in the reception name. Similar to how it's done to the building names in our campus: http://osm.org/go/0EujzVLy6?node=2727694798. Then the routing softawre can indeed find the correct way to the needed reception. -1 OSM is a geographical database and not a yellow-pages listing of hierarchically structured names. The name=Math Building of the XYZ university should be found because it is mapped on the campus, and not because it is named XYZ university - Math Building or consequently even worse ABC country - DEF town - XYZ university - Math Building Your ASML example is not good imho since acronyms are discouraged. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Sat, Mar 7, 2015 at 11:50 PM, Warin 61sundow...@gmail.com wrote: Do you 'navigate' to 'drinking water' or simply look for the closest one? Most would navigate to an address .. then look on the map for parking, then look on the map for the closest reception desk .. I think there is a difference between getting to a specific address and getting to a reception of the building located at that address. A building can be huge, or it can be surrounded with one-way or pedestrian streets. It's really useful to know the location of the reception well in advance. some of them are for all the firms in that location. I know from experience 3 distinct situations: 1) A large campus belonging to one organization has one or more receptions. In that case a reception can usually be identified by some name. 2) A large campus belongs to one organization but lends location to smaller companies (e.g. a start up company in a university). In that case a visitor will usually get an instruction to get to the reception of the larger campus, so that name helps again. 3) Many companies are hiring space in an office building, with a common reception. In that case, unless the building has a name, it's indeed challenging to name the reception, and it should be mapped without the name. Anyway, IMHO we don't need to agree on this. The mappers must be able to find a reasonable solution in each specific case. Situations can be pretty different, and naming may or may not be helpful. I would add a recommendation to name the reception in the wiki, but the final decision should be left to the mapper. In any case, being able to know where the reception is located is better than not having that possibility at all, even if routing is not supported. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 8/03/2015 10:22 AM, Andreas Goss wrote: Do you 'navigate' to 'drinking water' or simply look for the closest one? Depends if I said I will meet someone at drinking water spot xyz or I'm just looking for some water. most would navigate to an address .. then look on the map for parking, then look on the map for the closest reception desk So that's the _quality_ of data you are fine with in OSM? Why do we even tag house numbers then? Finding the right street and then looking at the numbers is even easier than this, don't even have to get out of the car. Small point ... The data may be correct and of high quality .. but missing what you want .. thus lacking detail, resolution or quantity ... not quality. Lacking quality would be, say, if the node were displaced .. say 2 kms. Or if the name was wrong. Most of 'my' local area has no OSM house numbers .. nor are residential buildings mapped, there are a few missing street names too. The level of data resolution and quantity is up to the contributors, their time and inclination. Before I map house numbers .. I think the missing street names should be done? You may think that address numbers are more important than reception desks ..I don't, simply for the reason you have given above looking at the numbers is even easier than finding a reception desk in a facility .. particularly when a multi building facility. A name of the reception desk would help ... but some of them are for all the firms in that location. Then why isn't this addressed at all in the proposal? There are many possibilities. Covering them all? I'd rather leave the variations up to the mapper .. they are inventive and are on the ground so know the situation better than I could possibly imagine it. The ones I know of are simple .. at least I see it that way. What you have I don't know and won't try to predict what the best possible solution is for something I can only guess at... Sorry but my crystal ball is broken. If there were a set preference that covers all (or at least most) cases then state it .. I've got no firm idea of what solution that is. - This is ONE case that I know very well. A group of buildings - all on one site. One major firm owns the site... but leases parts off to other firms .. One reception desks for all. One address for all (yes all the buildings have one address). The reception desk is poorly marked .. has been for many decades. Not uncommon to find visitors wandering around lost. == thus the reception desks exist in an area with one address, so one address. I'd not name it .. the firms change over time , but the reception desk remains. Possibly name the operator as the site owner. But I'd leave the name off. - Relations which could handle this are not mentioned once. First time that has been mentioned. I've not though of it. I'd see that as another proposal ... First get a tag for 'reception desk' .. whatever it is called and where ever it is placed on the OSM data base. Then see if a relationship is needed .. and if that relationship may be used on other features too. Like 'my' proposed relationship for area- steps? And again how would you name it if it was just one of multiple recpetions desks for one facility. Facility name = operator=* name=Gate 1? So if the reception has no name then name= stays empty? Do I use the plant name as operator? Or the company name? Is it possible to put that in operator or official_name, or is the name assumed because the point is inside the landuse? The basic answer would be .. how do the people there name the desks? Use that - the locals will understand it, visitors may be given that name too. See the wiki - http://wiki.openstreetmap.org/wiki/Key:name The common default name. Multiple reception desks for one facility? Do they have separate functions? Or the same functions in different locations? I'd use a name appropriate to the circumstance! I don't know the circumstance .. so don't know the answer. There are too many possibilities that exist for your given question. -- Request For Comments ... I see this as part of improving the proposal .. not as showing a complete, fully functional for all possible things, fault free tag. If only complete fault free and all encompassing tags are to be proposed then there will be NO tags. By all means comment on things that could be better ... and hopefully suggest possible solutions. Don't think a proposal should have addressed all possible things.. if they could see the world and all its problems, and then solve them in the bast possible way .. well OSM would not need proposals .. they would simply go straight to tags! And there would be no need of the tagging group. Criticism that a proposal is incomplete, should have address some issue
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 8/03/2015 10:51 AM, Andreas Goss wrote: It should be found because OSM is a geographical database and the reception, or the multiple receptions as you asked before, is/are contained in the campus of the facility. So bascially most of the time you would just tag amenity=reception_desk without any other tags and that's enough? Apart from that you are ignoring buildings with multiple companies and different reception desks, which I think I already brought up some weeks ago... At those locations .. what do the locals call the desks ? Use those names... If they all have the same name and the same function then there is no harm in them all beoing named the same or unnamed the same. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 8/02/2015 11:11 PM, AYTOUN RALPH wrote: I have to admit I admire the problem but do not have an answer. What I would like to suggest that dropping the desk part and just using reception could make it more conducive to the various applications being discussed. It could then be added as a subcategory to the area/building such as reception=desk...reception=area...reception=kiosk.. and would accommodate the problem of more than one type of reception within a complex such as an hotel I have always come across receptions .. as having a desk. And a person. Usually with a phone, brochures for information on the facility they service. (reception=tourism...reception=hotel). Or at an airport complex where multiple receptions exist such as hotel, car hire,etc. Each of those are in separate places in the airport complex. And are receptions for different services .. probably indicated by sub tags .. name= operator=? Using this would then also not clash with the amenity tag. Won't they then 'clash' with each other? Whatever sheme is used there will be clashes, where the clash is by location then simply separate them by distance - OSM resolution is something like 50mm. Hope I am not adding more confusion to the problem. Ralph (RAytoun) On 8 February 2015 at 10:33, Andreas Goss andi...@t-online.de mailto:andi...@t-online.de wrote: As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Well, you could have an amenity inside a very large bulding where you have multiple entrances. Then you could use the amenity node to indicate that it's actually placed at a certain spot, because the reception is there. In addition it makes it clear to which amenity the reception desk belongs, as a different amenity in the same building could have the reception desk at the other side of the bulding. Multiple reception desks in the same area would probably be operated for different businesses .. thus would be identified by the sub tags of name=, operator= ... ? __ openstreetmap.org/user/AndiG88 http://openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 http://wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Well, you could have an amenity inside a very large bulding where you have multiple entrances. Then you could use the amenity node to indicate that it's actually placed at a certain spot, because the reception is there. In addition it makes it clear to which amenity the reception desk belongs, as a different amenity in the same building could have the reception desk at the other side of the bulding. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I have to admit I admire the problem but do not have an answer. What I would like to suggest that dropping the desk part and just using reception could make it more conducive to the various applications being discussed. It could then be added as a subcategory to the area/building such as reception=desk...reception=area...reception=kiosk.. and would accommodate the problem of more than one type of reception within a complex such as an hotel (reception=tourism...reception=hotel). Or at an airport complex where multiple receptions exist such as hotel, car hire,etc. Using this would then also not clash with the amenity tag. Hope I am not adding more confusion to the problem. Ralph (RAytoun) On 8 February 2015 at 10:33, Andreas Goss andi...@t-online.de wrote: As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Well, you could have an amenity inside a very large bulding where you have multiple entrances. Then you could use the amenity node to indicate that it's actually placed at a certain spot, because the reception is there. In addition it makes it clear to which amenity the reception desk belongs, as a different amenity in the same building could have the reception desk at the other side of the bulding. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) +1 Amenity is very vague in general (), and a lot of things can be marked as such. So I'd prefer to use it only when it's an obvious choice or there is nothing better. What about using office? I was also surprised to discover that there was not key for booth in OSM. (And of course all currently available booths ended in amenity :) ) Shall we maybe introduce it? As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Cheers, Kotya ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On February 7, 2015 10:41:17 AM CST, Kotya Karapetyan kotya.li...@gmail.com wrote: Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) +1 Amenity is very vague in general (), and a lot of things can be marked as such. So I'd prefer to use it only when it's an obvious choice or there is nothing better. What about using office? I was also surprised to discover that there was not key for booth in OSM. (And of course all currently available booths ended in amenity :) ) Shall we maybe introduce it? As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Cheers, Kotya ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging I suspect what was meant was an amenity node contained within a larger entity that was mapped as something other than amenity. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Sat, 2015-02-07 at 17:41 +0100, Kotya Karapetyan wrote: ... Amenity is very vague in general (), and a lot of things can be marked as such. So I'd prefer to use it only when it's an obvious choice or there is nothing better. Well, while I agree that Amenity is pretty general, but amenity=reception_desk is about as specific as you are likely to get. Amenity is a go to when a mapper is looking for a tag, new ones such as Office or Booth make the discovery process a little harder and don't, IMHO, deliver any extra clarity. David What about using office? I was also surprised to discover that there was not key for booth in OSM. (And of course all currently available booths ended in amenity :) ) Shall we maybe introduce it? As this tag is always going to be used within another entity I think we should rather look towards something like indoor tagging or other subtags. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. Not to defend the amenity key, but I wonder if there is a need to tag the reception if the whole object (including the reception) deserves just a single node. Cheers, Kotya ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 8/02/2015 3:41 AM, Kotya Karapetyan wrote: Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) +1 Amenity is very vague in general (), and a lot of things can be marked as such. So I'd prefer to use it only when it's an obvious choice or there is nothing better. What about using office? An office - such as office=government may well have a reception desk. If you mark both you will have an office inside an office unless you do an internal multipollygon .. lot of work for what maybe a single node to mark the location of a reception desk? I was also surprised to discover that there was not key for booth in OSM. (And of course all currently available booths ended in amenity :) ) Shall we maybe introduce it? Cheers, Kotya The only 'booth' I can think of to map would be an 'information booth' .. and that already exists .. twice over ! http://wiki.openstreetmap.org/wiki/Key:information http://wiki.openstreetmap.org/wiki/Proposed_features/information ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 7/02/2015 9:15 PM, Andreas Goss wrote: Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) As this tag is always going to be used within another entity Always is such a large word. What about a hut that is used only for reception? Such as a campsite reception hut? I think we should rather look towards something like indoor tagging or other subtags. Such as? Suggest some tag that could be used.. the suggested tag does not have to exist yet .. but some idea of what is to be used instead? Note that tap can be used indoors, as can shower, toilet.. and so on. In addition using amenity for reception desk would for example prevent you from placing it on the node of the amenity and use one node for both. If there is one node then there would be no need to mark the reception desk location.. the need for this tag is to show where the reception desk is in some large feature ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Maybe there is a need for something like… a tag for office=* which may cover the different public or employee facing building types where the common facilities you would find in each category would be taggable, so you can tag a point or a building as certain types of facilities. office=human_resources office=reception (no desk, because it could be a desk, building, hut, area) office=records office=break_area office=changing_room I’m having difficulty about what “sections” or office_centric amenities could exist outside of existing general amenities, so maybe this is a crap idea - but it would the the alternative would to be to put it into amenity, or ignore the “commercial” reception desks (which is a big mistake, I think) and make hospitality=* key (for hotels, camps, etc), but I think it would be similarly difficult to fill out a that tag either, as it would be full of general amenities (gym, laundry, restaurant,) hospitality=item_check is the only one I can think of off the top of my head. so maybe amenity=reception(_desk) is the best idea. Javbw On Feb 8, 2015, at 8:20 AM, Warin 61sundow...@gmail.com wrote: On 8/02/2015 3:41 AM, Kotya Karapetyan wrote: Amenity is the best fit for this tag. I disagree. (Usually that just means I didn't find anything better) +1 Amenity is very vague in general (), and a lot of things can be marked as such. So I'd prefer to use it only when it's an obvious choice or there is nothing better. What about using office? An office - such as office=government may well have a reception desk. If you mark both you will have an office inside an office unless you do an internal multipollygon .. lot of work for what maybe a single node to mark the location of a reception desk? I was also surprised to discover that there was not key for booth in OSM. (And of course all currently available booths ended in amenity :) ) Shall we maybe introduce it? Cheers, Kotya The only 'booth' I can think of to map would be an 'information booth' .. and that already exists .. twice over ! http://wiki.openstreetmap.org/wiki/Key:information http://wiki.openstreetmap.org/wiki/Key:information http://wiki.openstreetmap.org/wiki/Proposed_features/information http://wiki.openstreetmap.org/wiki/Proposed_features/information ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Reception is used for tourists, but also is common for any large office complex or even a industrial plant. People visiting the plant (for work related activities) would go to reception, check in, and get a visitors badge. I think there is a difference between a person on vacation and a product rep having an appointment at a car parts plant, but both have reception. Since the object is part of another object - a hotel, office, etc - it is an amenity of the building, whose purpose is tourism. But people visiting a factory complex and looking for visitor check-in aren't really tourists, are they? I think amenity is the right key. Javbw On Feb 6, 2015, at 9:58 PM, Janko Mihelić jan...@gmail.com wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. I think the idea of =reception_desk could be applied much more widely than just tourism. Commercial sites, mining sites, the list would be quite long. So, I'd vote for amenity= David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On February 6, 2015 4:10:23 PM CST, David Bannon dban...@internode.on.net wrote: On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote: Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. I think the idea of =reception_desk could be applied much more widely than just tourism. Commercial sites, mining sites, the list would be quite long. So, I'd vote for amenity= David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging Agreed. The amenity tag is better, as otherwise we would need a separate tag for each industry. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Fri, 2015-02-06 at 11:16 +, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. In a lot of cases, we'd probably see a larger area mapped as something, be it caravan park, mine, whatever. Then a single node within that space would represent the reception_desk. Clearly the larger area would not be tagged =reception desk would it ? The usefulness here it to identify where, in the larger area, the reception desk is. Hmm David For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... Best Dan * http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site 2015-02-06 2:03 GMT+00:00 Warin 61sundow...@gmail.com: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
I think this proposal is very relevant for some larger hotel and resorts. I've been myself a few times in a situation when I had to search for the reception over a large area. It can be a trouble if you simultaneously have to get rid of your car in a parking restricted area. Same for multi-entrance campuses where only one door can be used by guests (has a reception). On Fri, Feb 6, 2015 at 6:18 AM, Paul Johnson ba...@ursamundi.org wrote: This seems to have a bit of overlap with information to a large extent. Most have tourism information for the area they're located and vicinity and can provide a lot of the same stuff as a general tourism information office would. They just also rent space to park an RV (or even an RV or cabin), or throw up a tent. On Feb 5, 2015 8:07 PM, Warin 61sundow...@gmail.com wrote: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Hi, No big objections from me, sounds useful. However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... Best Dan * http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site 2015-02-06 2:03 GMT+00:00 Warin 61sundow...@gmail.com: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On February 6, 2015 9:37:20 AM CST, Tobias Knerr o...@tobias-knerr.de wrote: On 06.02.2015 12:16, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... I believe this is not necessary as long as the reception is contained in only one outline of a relevant feature (hotel, motel etc.), which will cover almost all cases. Of course, for the special cases you could use a relation, but that should be limited to those cases. What I consider a bit odd, by the way, is the amenity key. Receptions are usually not amenities by themselves, but instead part of an amenity. Perhaps a new key for this kind of sub-feature would be in order? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging One circumstance where the relation would be useful would be if you were mapping an office building, and wanted to map both the reception desk for the entire building, and also reception desks for individual office suites within that building. This is a common circumstance when a building contains offices for several different companies. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On Feb 6, 2015, at 2:18 PM, Paul Johnson ba...@ursamundi.org wrote: This seems to have a bit of overlap with information to a large extent. Most have tourism information for the area they're located and vicinity and can provide a lot of the same stuff as a general tourism information office would. They just also rent space to park an RV (or even an RV or cabin), or throw up a tent. -1 information is a place to get information, usually tourist information. Where to actually go to register for your space / hotel room / name badge / visitor check-in / visitor-checkout is a very different concept than an info kiosk or tourist info desk. Most large train stations have information booths. but its different than the ticketing window. Most hotels have a large reception desk. the information booth outside for tourists passing by is a information point. a reception desk at a hotel also has the ability to order food, but we would not confuse that with a restaurant. considering the phase “reception” is so widely used int he hospitality industry, and it can also be used for check-in at a motel, camp, or other corporate facility that handles visitors along with the working staff (like a big company office or complex where one building or space is designated reception for the visitors. It seems like a good idea to have the amenity. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, tourism=information, it's only logical to use the same key. Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
On 06.02.2015 12:16, Dan S wrote: However it occurs to me that it would be useful to have some way of indicating _what_ it is the reception for. For example, if it was part of a site relation*, then a role like role=reception would connect it to the larger entity in a meaningful way. That might be a suggested tagging option... I believe this is not necessary as long as the reception is contained in only one outline of a relevant feature (hotel, motel etc.), which will cover almost all cases. Of course, for the special cases you could use a relation, but that should be limited to those cases. What I consider a bit odd, by the way, is the amenity key. Receptions are usually not amenities by themselves, but instead part of an amenity. Perhaps a new key for this kind of sub-feature would be in order? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
This seems to have a bit of overlap with information to a large extent. Most have tourism information for the area they're located and vicinity and can provide a lot of the same stuff as a general tourism information office would. They just also rent space to park an RV (or even an RV or cabin), or throw up a tent. On Feb 5, 2015 8:07 PM, Warin 61sundow...@gmail.com wrote: Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Reception Desk
Hi, Request for comment on new tag 'amenity=reception_desk' https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a sub key of camp_site=reception. As 'Receptions' are numerous outside of camp sites I think it is best to have them available for use under other things - like hotels. So the new tag. 'reception_desk' .. should separate it from other types of receivers .. like radio receivers. Amenity is the best fit so amenity=reception_desk. what do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging