[Tagging] Feature Proposal - RFC - Reception Desk

Warin 61sundowner at gmail.com
Sun Mar 8 00:57:06 UTC 2015

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 

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

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- 

> 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 

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150308/ca1fd083/attachment-0001.html>

More information about the Tagging mailing list