[Tagging] Feature Proposal - RFC - Reception Desk
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
> 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
> 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...
More information about the Tagging