<div dir="ltr">On Fri, Sep 29, 2017 at 1:16 PM, Mark Wagner <span dir="ltr"><<a target="_blank" href="mailto:mark+osm@carnildo.com">mark+osm@carnildo.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">It's reasonable to map a hotel as any of<br>
<br>
1) A point [...].<br>
2) A building [...]. </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
3) An area [...].<br></blockquote></div><br>I don't think anyone here is arguing that point. All three are<br>reasonable.<br><br>But note that a building is also a point or an area, so we are talking<br>about either<br><br>* A point - There's no ambiguity here, I discuss it no further<br><br>* An area. Let's look at areas.<br><br>A renderer - any conceivable renderer, not just the default renderer -<br>to do a good job needs to decide "is this area a building, or is it<br>not?"<br><br>(This is not a discussion about "tagging for the renderer" - it's<br>about providing sufficient information in tagging that some<br>conceivable renderer could render correctly. Without that information,<br>there is no rendering.)<br><br>To decide whether the area is a building or not, the rule could be:<br><br>* An area with amenity=hotel is a building unless specified<br> otherwise (with building=no).<br><br>* An area is a building only if it has building=*, irrespective<br> of any 'amenity=*' tag that attaches.<br><br>* Something else, implying a complex heuristic.<br><br>Any complex heuristic is likely to be wrong in some significant<br>fraction of the cases, so the first two are the only things that are<br>likely to get us correct rendering. They have consequences:<br><br>* If we choose the "building until proven otherwise" route,<br> a mapper will have to explicitly specify 'building=no' when<br> tagging grounds. This is, to my mind, counterintuitive;<br> ordinarily, tags specify what an object is, not what it is not.<br><br>* If we choose the "not a building unless accompanied with<br> 'building=*', then, for the common case of outlining a building<br> and saying 'this is a hotel', the mapper must also specify<br> 'this is a building.' This doesn't bother me quite as much,<br> since most hotels will have associated grounds, and since<br> misrendering a hotel building as hotel grounds is unlikely<br> to give a map reader very much confusion.<br><br>In turn, these decisions impact the correct settings of defaults in<br>tools like iD. In either case, when an iD user outlines an area and<br>asserts 'this is a hotel', we need to offer a choice of 'is this the<br>building or the grounds?'<br><br>There may be an obvious default for this choice. If we follow the Wiki<br>suggestion that the 'hotel' is the building, then the we should either<br>present 'building=hotel' in addition to 'amenity=hotel' as the<br>default, giving the user some way to turn off the 'building' key. If,<br>instead (my preference), we update the Wiki to indicate that an area<br>feature should represent the hotel's entire facility (buildings,<br>grounds, appurtenant restaurants, laundries, parking garages, etc.),<br>then a sensible default would be to leave the 'building' tag off, and<br>let the user state affirmatively that the hotel is coterminous with<br>its building.<br><br>In addition, there's the question of whether the Wiki should be<br>updated to indicate that tagging the grounds as well as the building<br>is acceptable practice, or even recommended.<br><br>So there are several interrelated questions.<br><br>My beliefs, already stated.<br><br>0. It's reasonable to tag the grounds as part of the<br> facility, particularly since a facility may comprise<br> multiple buildings and other features.<br><br>1. Fix the Wiki to indicate that such a tag on an<br> area implies that it is tagging the entire facility.<br> (In the spirit of 'map what you know', it's conservative<br> and acceptable to start with tagging just the building,<br> of course.)<br><br>2. Render the area as a building only if it's 'building=*'.<br> (Do not assume that it's a building. Requiring explicit<br> 'building=no' is counter-intuitive, error-prone, and<br> inconsistent with our treatment of schools, universities,<br> and hospitals. Complex heuristics will never be right.)<br><br>3. Whether the iD default should be 'hotel building' or<br> 'hotel grounds' is something about which I have<br> no strong opinion. It would be a good idea to make it<br> clear which one has been chosen and that the<br> alternative exists. I'm not familiar enough with iD's<br> user interface to suggest an appropriate presentation.<br><br>These arguments apply to nursing homes, office campuses,<br>factories, and so on; any case where the facility may<br>comprise both buildings and grounds. Ideally, all should<br>be handled the same way, on all four points (tagging the<br>grounds preferable; Wiki giving correct advice; rendering<br>as a building based on the 'building' tag, not assumed<br>from an 'amenity' or other tag; similar defaults in the<br>user interfaces.)<br><br></div></div>