Proposal:Reception point

Reception Point
Proposal status:	Rejected (inactive)
Proposed by:	Warin61
Tagging:	`amenity=reception_point` Data item
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-23
RFC start:	2015-06-24
Vote start:	2015-07-08
Vote end:	2015-07-22

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

The use of the word 'point' is to reduce the possibility that this tag is misused for 'wedding reception', and that it identifies the place where the greeting/reception takes place rather than a large area usually set aside for waiting.

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

The above represents what should appear on the resulting wiki page. Below are presented the explanation of the need for this tag and why this method is used.

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_point

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_point

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_point

The amenity key is used for "an assortment of community facilities". You could view the reception_point 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_point.

What value?

Reception by it self could be confused with GPS reception, radio or TV reception, wedding reception. The use of the additional word 'point' would help reduce the misuse of this tag and influences the use of a single node for this feature.

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_point. 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_point" as it would not identify the location of the reception_point. 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.

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 approve this proposal. Let's get this proposal off the dissecting table and into practice. IMO reception_points are amenities, they are not tourism specific, and this proposal is a good compromise for those objecting to the use of the term "desk". AlaskaDave (talk) 17:57, 24 June 2015 (UTC)
I approve this proposal. The best of the 3 current reception proposals. Warin61 (talk) 01:01, 8 July 2015 (UTC)
I approve this proposal. —M!dgard [ talk | projects | current proposal ] 21:25, 10 July 2015 (UTC)
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:28, 13 July 2015 (UTC)
I oppose this proposal. "Reception point", as such, sounds confusing: why "point"? It's never called like that in general speech. It is a poor replacement for "reception desk" (which needed replacement because it's not necessarily a desk) and "reception" (which can be confused with radio reception or reception as event). See also reception_area. --Kotya (talk) 09:17, 28 July 2015 (UTC)