The one pub that I plotted, I added when I was doing a couple of nearby schools and noticed that it was missing. I used exactly the same principle as for the schools - an outer “amenity=pub” polygon and an inner “building=pub” for the actual building.
http://www.openstreetmap.org/way/389684953 Personally, I think that this is fine. The fact that the pub icon sits in the garden is hardly the end of the world, and the garden _is_ part of the pub after all. And I bet if you turned up at the location you’d be able to spot where the pub was :) My opinion, for what it’s worth, is that there is way too much inconsistency in the way that things get mapped in OSM which makes it difficult to understand the data. Country pubs, in particular, will often have car parks & gardens as well as the physical building, and using an enclosing polygon is surely the right way to make sure that they are all kept together - and using a style of data that then compares directly to other amenities like schools, hospitals, parks … Cheers Stuart On 14 Mar 2016, at 10:26, Jez Nicholson <jez.nichol...@gmail.com<mailto:jez.nichol...@gmail.com>> wrote: I normally plot and tag a pub building as an area. I've noticed a few points appearing for existing pubs. They may be coming from the new OSM online editing programs. On Fri, 11 Mar 2016 at 22:48, Neil Matthews <ndmatth...@plus.net<mailto:ndmatth...@plus.net>> wrote: It's not my preferred style -- I prefer to draw the building and tag that. I'd expect to put the name and address on the building too! If I tag a large area, then there's a high likelihood that it'll adversely affect routing. Conversely tagging large areas makes the map look more complete. However, if I can't rely on a rendering to help me locate a public house (emphasis on the house :-) accurately on a map, especially at the end of a long day mapping, then that doesn't rely help. And since I use mapnik renderings and OSMAnd+ it's important that they work well -- especially as that way I find other non-obvious issues. Schools are somewhat different in that they aren't generally open to the public -- it's probably more important to map the entrances on the perimeter -- as more and more schools are fencing kids in and public out. But maybe we should use bar to mean where you actually get served? And pub for the whole area. Cheers, Neil On 11/03/2016 17:26, SK53 wrote: Earlier today browsing Pascal Neis summary of changesets I noticed a comment about reverting a duplicate pub node, and glanced at the changeset<http://www.openstreetmap.org/changeset/37749403>. 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. 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). The disadvantages, at least to my mind, are: * 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. * Pubs are licensed premises. The premises licensed usually relate to the building. * 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). * 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. * 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. 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. 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. 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. 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. Cheers, Jerry _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org<mailto:Talk-GB@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-gb _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org<mailto:Talk-GB@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-gb _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org<mailto:Talk-GB@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
