[Tagging] Feature Proposal - Voting - Reception Desk

Kotya Karapetyan kotya.lists at gmail.com
Wed Apr 1 10:10:17 UTC 2015


Hi Warin,



> 10 state it should not be an amenity key and most of those are for it
> being in the tourism key.
> My failing there for not explaining that it has applications to offices,
> industries and educational areas where tourism is not an appropriate key.
>

In my opinion, it depends on personal experience. For me the value of this
tag for company, hospital, university and other non-touristic facilities is
clear. For someone the word "reception" may only associate with hotels.

 1 says it is not necessarily a desk.

> I have never come across one that was not a desk - telephone, public
> address system and sign in in all housed on a desk.
>

It's true that it's not always a desk and usually is much more than a desk.
However it's still called a desk :)
I am not a native speaker, but I think it's a standard term for a reception
facility.



> 2 (with another supportive comment from someone else) says it should
> embedded in 'the indoor tagging scheme'.
> The 'indoor tagging scheme'? That is going to have the same kind of
> problems with the tags for toilets, telephones, shops swimming pools, etc
> etc. The problem posed by this tag exists for many others and will need to
> be addressed by the indoor tagging system NOT by this tag alone.  The
> 'indoor tagging system' looks to be in evolution ... and will probably take
> some time before being generally accepted.
>

I think there are some keen proponents of indoor tagging. There is
definitely an advantage of being able to specify where the desk is located
exactly. Moreover, it's kind of natural, since that's the implicit reason
for your proposal: to specify where one can find the reception.

How is reception desk shown to be part of another feature? By its location
> in most instances. It has also been suggest that a site relation could be
> used. The site relation looks to be in some state of 'proposed'... I could
> not hazard a guess as to when it will progress onwards.
> (proposed) relation
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
>
> Also note the other proposal
>
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
>
> I don't see how the problem can be addressed by the simple value of the
> proposed reception_desk .. particularly as it is a problem/solution for
> other things too?
>
>
This is the only critically important aspect IMO. For a building hosting
multiple organizations, there should be a way to attribute the reception
properly. In many cases it logically follows from the location. Not in all
probably. My suggestion would be to introduce the tag as is, and add a
relation when possible. The tag definitely adds value in many cases even
without the relation.


Cheers,
Kotya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150401/1e5627ec/attachment.html>


More information about the Tagging mailing list