Proposal:Reception
| Reception | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | Warin61 |
| Tagging: | amenity=reception |
| Applies to: | node |
| Definition: | a place where people are received by an organisation. |
| Statistics: |
|
| Rendered as: | an attendant at a bench/desk |
| Draft started: | 2015-06-24 |
| RFC start: | 2015-06-24 |
| Vote start: | 2015-07-08 |
| Vote end: | 2015-07-28 |
Rejection Summary
Lack of votes!
Only one vote opposed;
- Should include tagging for areas
- Lacks description of relation/s that could be used
Proposal
A Reception provides a place where people (visitors, patients, or clients) arrive to be greeted, admitted to an organisation (e.g. camp site, hotel, school, business).
How to Map
Map the reception place - not the waiting area nor the building.
On a Node - where the reception takes place.
As a member of a relation. When a relation is declared you include the node/way/area that contains the tag reception as one member of the relation.
Additional Tags
- operator=*
- phone=*
- opening_hours=*
- name=*
- level=* for multi level indoor tagging
Rendering
As a receptionist, represented as a head and shoulders figure over a bench/desk represented as a line, in the amenity colour of brown.
Rationale (Verbose Explanation)
It is particularly useful to know the location of the reception when it is located away from the typical place (near a front entry) or where there is only one amongst a number of large buildings. First seen as a suggested Proposed features/Extend camp site extended tag for camp sites], thought to have a wider application to offices, hotels, hospitals and educational features.
What key?
- Tourism=reception
The tourism key is used for "places and things of specific interest to tourists". While this works well for hotels, camp_sites it does not work for offices - say a government department, nor for a university. In those cases the facility is not for tourists. In fact my first application for this tag is a large industrial/scientific/research facility where the reception is some 600 m from the 'front entry' and is hard to find. It is not a tourist site in any way.
- office=reception
The office key is used for "a place predominantly selling services". A reception does not commonly sell a service, it usually directs to a service.
- amenity=reception
The amenity key is used for "an assortment of community facilities". You could view the reception as similar to a toilet or telephone (both key:amenity), they are present on tourist sites, businesses/offices and educational institutions. They provide a needed facility to tourists and locals alike.
Of these 3 keys, amenity is the 'best' existing key for reception.
What value?
Reception by it self could be confused with GPS reception, radio or TV reception, wedding reception.
To guard against the wedding reception I will make another proposal for that key/value to be added to OSM.
The use of reception for GPS, radio or TV is usually confined to the notes field, I am hopefull that this will not prove to be a problem.
Association with parent
The reception would service some other feature (the 'parent', an office, camp_site etc) and should be associated with it. These may share the operator and/or name tags being the same for both. The relation between the reception and its' parent feature may be indicated by;
- the reception being enclosed by the parent feature.
- the proximity of the reception and the parent feature.
- A site relation. See site
This is something that that applies to some features and could be addressed by a wiki page on the subject of 'associating features'?
Indoor Mapping?
Many of the present tags in use will need to be considered by any indoor mapping system. The addition of this tag does not add any complexity to that, it is similar to the tags toilet, telephone, all the key:office and key:shop values. A solution for those tags should also work for reception. I see no reason why this tag has to be 'special' in some way for the indoor tagging.
See the indoor mapping wiki page.
Possibly the most relevant is the level=* tag.
This is something that could be addressed by a wiki page, associated with the indoor mapping wiki page.
Relations
This can be an element of a relation. But not as a tag on a relation (like a name, operator or contact could be). The relation has a declaration of "type=" .. in that area you cannot have "reception" as it would not identify the location of the reception. The above is true for all amenity values.
What relations would it be used with? Those that link it to the thing it services (its 'parent'). There maybe others that I have not come across.
Examples
Any hotel will have a reception, as do many office, industrial, camp and caravan sites.
From Taginfo value=reception there are over 900 instances, most of those follow suggested extended tags for camp sites. Many of the rest are names for buildings ... probably where the mapper wants to identify where the reception is but lacks a tag for it.
There are a number of buildings in the data base with the name reception, this may imply a large area such as a hospital emergency departments reception area. Or it may simply be the mappers using the name to indicate where the reception is.
Features/Pages affected
Could be added to other wiki pages as a complimentary tag for offices, motels, camp sites, caravan sites.
On the OSM data base there are approximatly
- 557 camp_site=reception (previous proposal related to camp sites)
- 295 name=Reception
- 105 amenity=reception_area
- 60 amenity=reception_desk (previous proposal)
- 26 name=reception
- 11 name=Main Reception
- 11 office=reception
At least some of these show a need for the tagging of a 'reception'. Where the name=reception is used they are typically on a building usually within a group of buildings. I would think buildings named 'Reception' are few, rather the mapper is identifying the function and the mapper regards this as an important requirement.
These related tags may be changed over time as users become aware of this tag.
See Also
Previous proposal
Proposed Features/amenity=reception_desk
Alternative proposals
Proposed features/reception_area
Proposed features/reception_point
Voting
Instructions for voting. Log in to the wiki - top right corner of the page -scroll up. Then scroll down to voting and click on 'edit'.
Copy and paste for
yes - {{vote|yes}} ~~~~
no - {{vote|no}} ~~~~ Please state your reason/s for opposition!
Note The ~~~~ automatically inserts your name and date.
I oppose this proposal. It should be possible to map these features as areas. Plus there is zero explanation of the relation mentioned in the proposal. --Tordanik 11:30, 13 July 2015 (UTC)- I oppose this proposal. Can be confused with radio reception and reception as event. Also conflicts (mapping-wise) with information. I propose going for information=reception. --Kotya (talk) 09:30, 28 July 2015 (UTC)
