<div dir="ltr"><div><div><div>Earlier today browsing Pascal Neis summary of changesets I noticed a comment about reverting a duplicate pub node, and glanced at the <a href="http://www.openstreetmap.org/changeset/37749403">changeset</a>.<br><br></div>The pub had indeed been added again (and subsequently removed). However what caught my attention was that the amenity=pub tag had been applied to the entire area of the pub grounds (car park, buildings etc.). A quick query on IRC and Andy (SomeoneElse) also maps pubs this way, however rarely with as much detail as this particular one. The general alternative is to map pubs as areas on the building of the pub.<br><br></div>The obvious advantages of mapping the entire area of the pub property are largely to do with the immediate association of car parks, beer gardens, children's playgrounds with the pub and thus ready interpretation of things like access tags and resolution as to which car park belongs to the pub. This approach is clearly less cumbersome than using a relation, such as associatedCarpark (invented I believe by Gregory Williams in Kent).<br><br></div><div>The disadvantages, at least to my mind, are:<br><ul><li>Non-intuitive. Certainly I have never thought of mapping pubs this way, although I can see the point. I doubt that a newcomer to OSM would find this the straightforwardly obvious approach.</li><li>Pubs are licensed premises. The premises licensed usually relate to the building.</li><li>Where do we place tags associated with the pub premises which may apply also to other parts of the pub property (an obvious one would be opening_hours).</li><li>Peculiar rendering. In this case a pub icon in a car park. Even if we fully accept "not tagging for the renderer", let's consider how we can tell renderers to improve icon placement. Andy suggested on IRC a label node, but this implies a relation: do we want to replace a simple node &/or area tag with a node, an area & a relation? And then ask the Carto-CSS team to deal with it? It seems to me that this pushes the bar too high not just for inexperienced mappers but also those of us who have been at it for a while. In the meantime the CartoCSS rendering will look rather daft in such cases.<br></li><li>Consistency. In general pubs will get mapped initially as nodes over the pub building, and attributes on a node easily transfer to a building outline + (usually) building=pub. In particular the node & area centroid will tend to be very close. Thus the two different ways of mapping relate to each other in a clear way.</li></ul><p>This issue of course is more general than pubs. For instance we map schools, colleges, universities and hospitals as areas and place all the relevant tags on the area. Churches & other places of worship, on the other hand, tend to have the amenity tag placed on the building. (This makes sense as in many cases it is the building which is the place of worship not the grounds). Also, I certainly will map a supermarket as the building rather than the whole area including car parks, petrol stations etc.</p><p>Obviously I prefer for supermarkets, places of worship and pubs that the area mapped should be the building. However I can equally see that there are certain issues which are otherwise intractable where mapping the whole area offers some advantages.</p><p>One approach which would reflect my own mapping approach would be to tag the complete area associated with the pub as landuse=retail, with a tag such as retail=pub. This would require no more additional OSM elements than used at the moment, and would provide for the identification of associations with car parks etc (and would work fine with multipolygons for pubs where the car park is across the road or otherwise removed from the pub.</p><p>This is an example of how as more stuff gets mapped different styles evolve. Neither is specifically wrong or right, but it would be nice if we could find a consistent style which satisfies most needs. <br></p><p>Cheers,</p><p>Jerry<br></p><p><br></p><p><br></p></div></div>