How would you tag a pub where dogs are allowed in the front bar though not in the dining area? I know for wheelchair access, you can use wheelchair=limited if only some areas are accessible by wheelchair. On that basis, would it make sense to tag the pub as dog=limited?
I think this is a case for Any tags you like - OpenStreetMap Wiki . Basically, if the tag seems correct and there is no better, established one, it is correct, even if the wiki doesnt describe it.
There are also 27 dog=limited cases on the map already, it might even be worth editing the wiki to explain that.
I think I would add an additional dog:description=* tag to explain the situation further. Limited is a nice and simple, machine readable way to convey some information, but that additional tag helps explain the bar and dining area situation in more detail.
4 Likes
I think this is a sensible tag but it obviously don’t say anything about this:
Although you could add details in note I doubt that’s a formal way that would be used by any data consumers.
Could we use conditional formatting? Something like: dog=yes (for the pub) + dog:conditional = no @ restaurant (or dining_area or whatever value makes sense).
I’m not sure we’re at that point yet. The documented values have orders of magnitude more usage and we haven’t really agreed on it being the best approach yet.
1 Like
All of dog=limited + dog:conditional= + dog:description= could be added. They have different uses and possible compatibility.
Besides area, another previous question on handling How to tag when dogs are allowed but only with muzzle?
As described there, in general, dog= is another wild west/mess. The documented new additions =designated and =outside already falls apart quickly. Other situations needed to be solved include using carry bags/cases/cages, moving in trolleys, and wearing diapers.
Ideally some *:dog=yes + *:dog=no can be used for the 2 areas. The bigger problem for that, or for a predefined condition in dog:conditional= (you can actually use quoted text as freeform comments), is that eateries don’t actually have the areas defined in the first place.
Details
indoor_seating=bar_table does exist documented. But it isn’t limited to front bar, as illustrated by the 1st photo. File:AC3 Bistro bar tables.jpg - OpenStreetMap Wiki
There are 2 *:dining_room= only. Here it’s isn’t rooms. dining= seems to be used for whether route=train have dining cars.
Therefore I might suggest inventing indoor_seating:dining_area:dog= + indoor_seating:front_bar:dog= (unspecified positives and negatives, vals can be discussed independelty)
One thought I have for front_bar is technically the term refers to the front, in contrast to “back bar”. It should be bar_counter ? And then the next question is restaurants can have counters unrelated to alcoholic “bars” (cf bar= ), so counter_area ?
With all that’s said, the other more fundamental problem for the 2 *door_seating= is they are combining position and posture. There are outdoor and indoor standing spaces. (Not to mention dine_in= is not established yet, requiring the use of takeaway=yes + delivery=yes where =only can’t be used) With this mind, I would delay further details for this post, pending progress on that side some time in the future.
Thank you for the simplest suggestion.
I ended up going with dog=limited and adding more context to the dog:description tag. I’m not convinced creating a separate POI for every aspect of a pub - the accommodation, dining room, function room - makes sense, unless they have different names or it’s a very large building or multiple buildings.
Here are the tags I applied to the pub:
accommodation=yes
amenity=pub
building=yes
dog=limited
dog:description=Dogs are allowed in the main bar area and outside. Dogs are not permitted in the main dining or function room, nor the overnight accommodation.
food=yes
indoor_seating=yes
outdoor_seating=yes
2 Likes
A slightly more formal version of the description could be
dog:conditional = yes @ "bar area and outdoors"; no @ "dining area and accommodation"
2 Likes