Talk:Key:reservation

Additional values

Added values: yes. As there must be an opposite to no. And neither no or yes are the default. And members_only as in some locations only members may reserve in advance, other people cannot reserve, but reservation isn't mandatory either.

• I explicitly avoided yes as a value. Either you cannot make a reservation or you have two options: a) It is required that you make a reservation (i.e. you cannot access an object without a reservation), or b) it is recommended, but optional. If a user would find a yes as a value, she cannot tell if a reservation is optional or required, so it is a useless value for her. Kay D 12:34, 12 April 2012 (BST)

Well for many places it depends on the time, season, and so on whether it would be recommendable or not. Take a restaurant. It's open all day, but only over midday and from 6-8PM it is crowded. Those would be the only times where from an outsider, you might want to reserve. On the other hand the restaurant maybe doesn't like reservations for theese hours. Some other places might say they recommend you to reserve. Recommended isn't good at all from this sense, as we don't know who recommends it (users vs owner) and for which time it makes sense. I do agree that Yes is very generic, but recommendable on the other hand is not giving any more information either--Extremecarver 12:52, 13 April 2012 (BST)

• members_only is a good information to be added to an object, but how about specifying it in the access key?. Kay D 12:34, 12 April 2012 (BST)

No, member_only means everyone can come/use/do whatever, but only members may reserve in advance. Hence advantage to members, but not related to access at all. --Extremecarver 12:52, 13 April 2012 (BST)

optional

an additional value optional would be usefull, isn't it ? --Marc marc (talk) 08:29, 21 August 2019 (UTC)

If you accept „only“ as a standard, „yes“ would mean optional. —Dieterdreist (talk) 09:01, 21 August 2019 (UTC)

yes in osm is often "unspecified value that include all others exept no". So imho yes include optional recommended required members_only--Marc marc (talk) 09:31, 21 August 2019 (UTC)

I came here to write that too. I had thought of possible instead of optional though. —M!dgard [ talk ] 13:23, 20 January 2020 (UTC)

Addition of healthcare

I don't think it's useful to recommend this be used with the healthcare tag, It's usually implied with doctors and the like that they require an appointment. So tagging that you need an appointment to be seen isn't helpful in most cases, would just way over inflate the reservation tag with a bunch of un-needed yes values, and it's not a "useful combination" anyway. A better way to approach it IMO would be to tag for the exceptions by coming up with something like a drop_ins=yes/no/only key instead. Since that's the actual information most people are interested in. Otherwise, it would be something like tagging shop=grocery with food=yes. And people really --Adamant1 (talk) 01:30, 27 June 2020 (UTC)

You say "reservation is required so reservation=yes", but that would be reservation=required. reservation=yes is actually exactly the same as drop_ins=yes as you describe. (The section #optional above wants to fix this confusing situation.) The tag drop_ins would not solve any of the problems you describe if you think about it. Btw, my doctor accepts visits during consultation hours with or without reservation. —M!dgard [ talk ] 12:34, 27 June 2020 (UTC)

Also there is walk-in=* and Proposed features/Urgent care. --Chris2map (talk) 12:47, 27 June 2020 (UTC)

The presumed default is quite dependent on local/regional/national conventions, there can hardly be a global default for this. —-Dieterdreist (talk) 13:51, 27 June 2020 (UTC)