Proposal talk:Amenity=reception desk

What will the resultant page look like?

I agree with fly that it would be good to actually change the proposal page to make it closer resemble the tag description page. Currently it mainly addresses the RFC process and questions. As the result, there is no "good" page for which we could vote. All discussion could be moved to the Talk subpage. --Kotya (talk) 13:09, 7 Apr 2015 (UTC)

The wiki page on proposals suggests being verbose and providing all the persuasion on the proposal page. Further the past voting indicates people don't participate on the tagging group, possibly due to a lack of time and/or lack of English skills. In the same way they may ignore the 'Discussion' page too.

I have formatted the proposal main page with the upper section carrying what the resultant wiki page should look like, and the lower section with the 'rationale'.

That covers the main things. I do think 'we' should vote on what it is, not what it looks like? Warin61 (talk) 02:10, 9 May 2015 (UTC)

Relationship

To me this is a feature, that cannot stand alone for itself. Reception desk for what? For which amenity?

It can stand for itself, as the vending machine, the dinner room, the toilette, the sauna, the pool, the gym, the playground, etc. (!!!) in the hotel. But then a relation is needed. Indoor mapping 2.0!!!

--EinKonstanzer (talk) 20:53, 26 March 2015 (UTC)

It is used to find a reception desk in a large site. Discussion was on the tagging mailing list.--Jojo4u (talk) 22:32, 26 March 2015 (UTC)

I'm surprised that you consider this such a big issue. You place a node for the reception desk inside the amenity area. Done. No relation needed unless in very complex cases. --Tordanik 00:42, 27 March 2015 (UTC)

I don't want to make it more complicated as it is and it is maby not an indoor mapping feature. I just wonder how to evaluate that. The reception desk is inside an area (camping site, company premises, hotel, public bath, etc.) but is this enoght for a proper relation between the feature and the subject that the feature belongs to? Feature=vending machine, the dinner room, the toilette, the sauna, the pool, the gym, the playground, restaurant, kiosk, etc.

Thinking more far. I will change my vote to neutral as the feature is not harming.

--EinKonstanzer (talk) 07:52, 28 March 2015 (UTC)

A Bus Stop does not stand by itself either, it needs a road and a bus route. A road needs people and vehicles, so it needs to be connected .. usually to another road, though I do know of one road on an island that is connected by a boat. This same issue exists for a toilet on a camp site, a park or a mall.

I too, still thinking. But I think 'we' need some overview of the 'system' that OSM 'should' be following before 'we' can make better tags? Warin61 (talk) 08:15, 28 March 2015 (UTC)

Would the operator= tag be usefull? Used on Bus stops ... trying to see if there is a suitable existing tag. There is no relation used on bus stops, they just rely being close. Warin61 (talk) 09:12, 28 March 2015 (UTC)

Comparing with bus_stop, they mean absolutely nothing more than an aluminium pole with a square sign on it unless there is a route relation tied to it somehow (stop position in the road in front of the sign?), the same way a reception can be far away from the offices/amenities it serves, and there may be multiple receptions within a short distance of each other close to a main entrance, so therefor having it as a member to a type=site relation makes sense --Skippern (talk) 03:23, 22 June 2015 (UTC)

To me, it seems that relations are only very rarely necessary here. Most of the time, the reception will belong to the building it is in, or to some facility it is enclosed by. So relations only come into play in the rare case where you visit the reception of fa facility, then walk through some area that belongs to someone else entirely, and then enter the facility proper. And even then, a multipolyon might just be enough. For cases that need it, sure, use a site relation. --Tordanik 10:14, 22 June 2015 (UTC)

Previous Voting results

moved over from the main page

• I approve this proposal. Seems reasonable, and has some tagging strength behind it under different names. The wording above will need refinement however, to be more clear: the proposal should not have question marks or random speculation. Brycenesbitt (talk) 05:37, 28 February 2015 (UTC)
• I approve this proposal. Good addition for campings. Can be part of a relation as well, as most campings should be site relations with tourism=camp_site, amenity=shower,amenity=restaurant, etc. as members. It most definitely has to be an amenity like proposed as it is always part of a larger service. In the case of campings it usually is not indoor. I have run into situations that the camping recetion was outside the camping, a few blocks away from it. --Jan van Bekkum (talk) 06:19, 28 February 2015 (UTC)
• I approve this proposal. I'm not a fan of the amenity key here, but I don't have anything better to offer atm. --Tordanik 09:42, 28 February 2015 (UTC)
• I approve this proposal. yeah, better than nothing.--Polarbear w (talk) 09:58, 28 February 2015 (UTC)
• I approve this proposal. simple enough. especially useful for campsites more than hotels, I guess Danstowell (talk) 10:29, 28 February 2015 (UTC)
• I oppose this proposal. It's not simple at all. Using amenity=* for this makes it impossible to combine it with such POIs. Also why amenity at all? For me it looks like a "I didn't find anything better", I mean amenity=reception_desk can't even stand on its owm. --AndiG88 (talk) 15:56, 28 February 2015 (UTC)

-One would never need to combine this feature. The goal here is to locate the reception desk spatially, thus it would always be it's own node, and refer by default to the nearest enclosing way. If the nearest enclosing way is not enough, a site relation can be used to tie various features together. Brycenesbitt (talk) 00:00, 1 March 2015 (UTC)

-Spatially? Then why isn't indoor tagging mentioned once here? A relation can be used? Where does the propoal say that? "Applies to: nodes, ways or areas. Not to relationships?" It suggests I would use name= etc. Also default nearest enclosing way will work great when you have multiple floors, not to mention when you have nodes... --AndiG88 (talk) 10:45, 1 March 2015 (UTC)

-Why do you assume "spatially" implies indoor? Imagine for example a campsite with a reception near the entrance gate. And the relation thing: I take it Brycenesbitt is not suggesting that the reception_desk would be a relation, but rather saying that it can be connected to other objects using a relation (e.g. the "site" relation that some people use)--Danstowell (talk) 19:05, 1 March 2015 (UTC)

• I approve this proposal.--Jojo4u (talk) 09:53, 1 March 2015 (UTC)
• I oppose this proposal. The tag is related to tourism and not to amenity. --toc-rox 11:56, 1 March 2015

-Have you never seen a reception in a government building, a office complex or just a big company? --AndiG88 (talk) 15:37, 1 March 2015 (UTC)

• I oppose this proposal. The tag is related to tourism and not to amenity. --wambacher 12:13, 1 March 2015
• I oppose this proposal. The tag is related to tourism and not to amenity. --Fx99 (talk) 11:19, 1 March 2015 (UTC)
• I oppose this proposal. The tag is related to tourism and not to amenity.Also, would suffice: tourism = reception. An alternative proposal would be amenity=porters_lodge --RoGer6 (Rogehm) 11:21, 1 March 2015 (UTC)
• I oppose this proposal. The proposal seems to me too isolated, It should be embedded in an indoor tagging scheme. Seichter (talk) 11:26, 1 March 2015 (UTC)

-It's not only related to indoor items though. --Danstowell (talk) 19:05, 1 March 2015 (UTC)

• I oppose this proposal. The proposal Sems to me too isolated, it should be embedded in an indoor tagging scheme. User 5359 (talk) 15:06, 1 March 2015 (UTC)
• I approve this proposal. I see the benefit from being able to map the reception desk location. I also don't see the reasoning behind those opposing the amenity key. By definition, amenity covers "an assortment of community facilities including toilets, telephones, banks, pharmacies and schools." I don't see how a toilet in a hotel (as well as a parking entrance or a bureau de change) is drastically different in the sense of the category from a reception desk. Without a better top-level key I support the amenity. --Kotya (talk) 15:28, 1 March 2015 (UTC)
• I approve this proposal. +1 to Jan van Bekkum, Dkiselev (talk) 17:42, 1 March 2015 (UTC)
• I approve this proposal.--heilbron 19:29, 1 March 2015 (UTC)
• I approve this proposal. Davo (talk) 21:51, 1 March 2015 (UTC)
• I oppose this proposal. The tag is related to tourism. --Efred (talk) 14:28, 2 March 2015 (UTC)
• I approve this proposal. Also very useful for big industrial areas. Not necessarily related to tourism, so amenity seems to be the best alternative without inventing a new top-level key. --Mapper999 (talk) 15:58, 2 March 2015 (UTC)

So how do you tag it on a industrial complex when you have it at let's say Gate 1, Gate 2 and Gate 3? --AndiG88 (talk) 10:14, 7 March 2015 (UTC)

It does not say anywhere that there can be only one reception per site. So you can just map all three of them and if it's not obviuos where they belong to, you can use e.g. name, description or a (site) relation to assign them to the correct gate. Anyway, I think this voting should be about the tag itself and not about indoor mapping schemes or how to assign a feature to a specific site. These can be discussed separately and should have a separate proposal. I think amenity=reception_desk works well with all indoor schemes I know and also with site relations. --Mapper999 (talk) 19:05, 7 March 2015 (UTC)

• I approve this proposal. this is not related to tourism but to all kind of reception desks which can appear in all kind of context. --18:47, 2 March 2015 (UTC)
• I approve this proposal. Not only for tourism, this is very interesting for offices and big facilities Tuxayo (talk) 20:14, 2 March 2015 (UTC)
• I approve this proposal. Good solution for tagging a reception place in a large establishment (for example in a big hospital or university campus) Renecha (talk) 23:11, 2 March 2015 (UTC)
• I approve this proposal. I agree with the use of this tag, as it's as useful to know the entrance of a venue as its reception. --Gileri (talk) 17:32, 3 March 2015 (UTC)
• I oppose this proposal. It should not be an amenity, the definition is vague, and in most cases this should go under indoor mapping, which is quite a complex subject. --Skippern (talk) 17:45, 4 March 2015 (UTC)
• I approve this proposal. I approve but regret use of key amenity (office will be better) dHuyp, not Dhuyp! (talk) 13:04, 5 March 2015 (UTC)
• I approve this proposal. I don't know why people think this is for just tourism or indoor mapping. At a large complex, a visitor (not tourist) has to enter the complex, park, and make their way to reception - which is not always straightforward. This also applies to campgrounds and other outdoor (albeit tourist) things. Forcing it into tourism or wrongfully assuming that it is an inside feature - a room or a desk - is similarly like complaining why toilets in a park are mapped. Javbw (talk) 14:12, 7 March 2015 (UTC)
• I oppose this proposal. The reception is not necessarily a 'desk'. Vclaw (talk) 00:03, 8 March 2015 (UTC)
• I oppose this proposal. The tag is related to tourism and not to amenity; vague, half-baked OPerivar (talk) 06:54, 12 March 2015 (UTC)

IMHO amenity does include tourism, while tourism doesn't necessarily include amenity, and in the case of a reception it is very clear that these occur in all kinds of settings, from companies, universities to museums and congress centers, nothing that is particularly related to tourism. --Dieterdreist (talk) 10:48, 12 March 2015 (UTC)

• I oppose this proposal. per Vclaw Mateusz Konieczny (talk) 07:09, 12 March 2015 (UTC)
• I oppose this proposal. This tag needs more time. --Imagic (talk) 08:30, 12 March 2015 (UTC)
• I approve this proposal. --Dieterdreist (talk) 10:48, 12 March 2015 (UTC)
• I approve this proposal. Escada (talk) 16:42, 12 March 2015 (UTC)
• I oppose this proposal. amenity=* is wrong, should be tourism=* IMHO (mapping the feature reception desk is a good idea I'd support) -- /al 17:34, 12 March 2015 (UTC)
• I approve this proposal. Waldhans (talk) 23:00, 12 March 2015 (UTC)
• I oppose this proposal. Foxxi59 (talk) 13:16, 13 March 2015 (UTC)
• I approve this proposal.AlaskaDave (talk) 00:54, 15 March 2015 (UTC)
• I oppose this proposal. JB (talk) 12:04, 18 March 2015 (UTC)
• I oppose this proposal. I think that the key amenity is not the right place. --Mike-001 (talk) 14:10, 18 March 2015 (UTC)
• I neutral this proposal. Now neutral. See discussion page. --EinKonstanzer (talk) 07:55, 28 March 2015 (UTC)
• I oppose this proposal. Vademecum (talk) 00:02, 27 March 2015 (UTC)
• I have comments but abstain from voting on this proposal. I agree with Dieterdreist that amenity is better than tourism, but I also agree with those who consider it related to indoor mapping. I cannot imagine a desk permanently in open air. An amenity=reception_desk node won't do any harm, but I am curious how it can be used by data consumers. There may be one reception desk for new customers (buyers), one for existing customers (repair etc.) and one for deliverers. There may be a janitor who you can ask the way, and a service desk where you can ask for products, etc. --Fkv (talk) 21:35, 30 March 2015 (UTC)

If I have a mall building area object, and I place a restaurant node on it, do you assume the resautant is on top of the building? If I put a toilet node in a park, do you assume it is a toilet fixture sitting out in a field? If I have a large sprawling complex of 5, 10, 20, 30, or 40 buildings, and the road accesses all of them - I can drop a pin on the approximate location of the reception desk within the area object of the building it is contained in. How is that any differnet than a restaurant tag at a mall? Why is "indoor mapping" required whatsoever? If I placed and emergency=aed next to it, would you assume it is on the roof? no! It's in the building! Probably next to reception. We sprinkle node tags on buildings all the time and everyone assumes that means it is an object that is in or on the building (depending on context without a layer=tag) - so why is it any different for this tag? Existing tags will have to have their descriptions and use cases updated as we do move to truly indoor mapping - so why is the "classic" method of dropping a pin somehow not a good idea?Javbw (talk) 01:31, 2 June 2015 (UTC)