|
Tagging a pub as a single node or a building with amenity=pub seems well defined. See http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpub Some pubs, however, have their own car park, a beer garden and other facilities on site. To map these I have created an area that is tagged as landuse=retail and amenity=pub. This is the whole site. Then the car park is created with a separate area within the site and tagged amenity=parking and access=customers. A service road is added to join the car park to the public road. Separate areas are also created for any garden and the pub building. The best tags for the garden appear to be leisure=garden with access=customers. The best tags for the pub building appear to be building=yes. Schools use amenity=school for the site and building=school for the building, but building=pub isn't in the wiki although it is used over 1200 times. Then entrances to the building are tagged with entrance=main, etc. Any contact information such as website and phone are added to the main site area. Is this the best approach? Inspiration: - use of landuse=retail based on planning use classification, e.g. http://en.wikipedia.org/wiki/Planning_use_classes_in_England#Class_A4_.E2.80.93_Drinking_establishments - schools use amenity=school for whole site, see http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool - https://help.openstreetmap.org/questions/1103/should-i-tag-nodes-or-areas-for-amenity-and-tourism - use of entrance tag for sites, e.g. https://help.openstreetmap.org/questions/14078/tagging-large-sites-entrance-area - use of building=pub see http://taginfo.openstreetmap.org/tags/building=pub |
|
I would take a different approach as I tend to avoid relations where they are not warranted. In this instance I would tag as follows An outline with building=yes and all building related tags (address, height, roof, year built etc etc) Inside that, a node with amenity=pub and include all relevant tags beer_garden=yes, wifi=yes, guinness=yes etc etc Parking would be tagged with a polygon and tagged with parking tags as appropriate Think of it this way, if there is information related to the pub that you would specifically want to know about that, or any other pub, put it in the pub tag where it belongs In other words, keep it as simple as possible and think logically. |
|
Hi al_t, consider to add brand and / or operator to all the separate items as well together with acces=customers |
|
Apart from visualization, is this the best way to structure the data? If I were to query all pubs which have a garden in a given area, do you think it would be possible this way? A relation for the whole thing might make things easier. Also reminds me of the proposition to allow to tag different amenities within a camping as tags of a camping node. This second approach makes for a much simpler mapping experience (i.e. could be done from Osmand or a dedicated gardenpub app), and easier data consumption. But a less pretty map. Sorry if that's too philosophical an answer. 2
There is the site relation, but that should only be used when one cannot draw a polygon around the area, i.e. when the different parts are physically separated.
(13 Apr '15, 07:09)
escada
Thanks for the help. I was modelling my way of tagging pubs on that for schools - http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool So I thought a query like ST_Within ( see http://postgis.net/docs/manual-2.0/ST_Within.html and http://revenant.ca/www/postgis/workshop/joins.html ) might be the way to query whether a pub has a car park or garden. Do people do that?
(13 Apr '15, 10:27)
al_t
|
There is no reason, not to use building=pub. For the rest it seems fine. As Hendrikklaas wrote, you could add operator, but I would only do that in case you do not have an enclosing polygon for all parts.
Yes, I also feel meta data like operator and contact information should be just in one place. I was thinking the enclosing polygon as well.