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.<br><div class="gmail_quote"><div dir="ltr">On Fri, 11 Mar 2016 at 22:48, Neil Matthews <<a href="mailto:ndmatthews@plus.net">ndmatthews@plus.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    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!<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    But maybe we should use bar to mean where you actually get served?
    And pub for the whole area.<br>
    <br>
    Cheers,<br>
    Neil</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    <div>On 11/03/2016 17:26, SK53 wrote:<br>
    </div>
    <blockquote type="cite">
      <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" target="_blank">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>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Talk-GB mailing list
<a href="mailto:Talk-GB@openstreetmap.org" target="_blank">Talk-GB@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-gb" target="_blank">https://lists.openstreetmap.org/listinfo/talk-gb</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
Talk-GB mailing list<br>
<a href="mailto:Talk-GB@openstreetmap.org" target="_blank">Talk-GB@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-gb" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-gb</a><br>
</blockquote></div>