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