I want to raise attention to this page: http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes
which most of you certainly are aware of. This page is pretending to be a proposal page, but actually has become mostly a documentation page for several application programmers to document how they evaluate certain tags. By reading the discussion page it seems that different applications have sometimes different interpretations of the same tags. None of the definitions there have ever been voted on, and most have not even been discussed before they were put there. Wouldn't be a problem if it were logical, coherent and consistent, but unfortunately it isn't. These are some keys and values currently suggested on this page, their current definition, and why I think there is a problem: 1. height Approximate height - distance from ground to roof of the building (Roof, not antenna or spire for skyscrapers by default) -> generally height does apply to the height of the object it is attached to. If a building is "hanging" like a bridge between two buildings the "height" of the hanging building would in my understanding be from the lowest part of this building to the highest. I wouldn't count technical installations (like aircon-plants or antennas). Not sure for the underground parts of a building, but I'd expect most mappers not to take them into account (like a fence, height=2 would not be measured including foundations). 2. min_height=* Approximate height below the building structure -> is not a "height" or a "minimum height" IMHO. The intention is to tag the difference between the elevation of the ground and the elevation of the lowest part of the building (missleading tag name). Is very limited in use because would be semantically strange if adopted to tag amount a building is dug into the ground (basically this would lead to different tags for mapping the elevation of building extents, depending on the position of the building). 3. building:roof=* Roofing material -> is missleading, should better be "building:roof:material" 4. building:levels=* Number of stories of the building above ground. -> why only above ground? I find this missleading as well. The logical meaning of a tag "building:levels" would be "the total amount of building levels". If it is for the levels above ground, why not building:levels:above_ground ? The description could be enhanced to give advice for the case of split levels as well. In any case this should be the amount of actual levels of the building, void levels or voids below the building should not count (see 5.) 5. building:min_level=* Number of stories between ground and actual first existing floor -> I'd completely discourage usage of this key, and suggest to estimate the elevation of the lowest part of the building. Any approximation in a system which allows for detail can later iterate to more precise values, while an approximative system like this will in many cases never be able to get unambigous. There are lots of unknowns here: what is "ground"? How high are the void levels and based on what? Usually levels differ in height from one storey to another, ... 6. building:levelPlan=* What each storey is used for, Examples: 0-2: shop, 3-12: residential; 0: restaurant, 1: residential; -1: unused, 0: lobby, 1: restuarant, 2-12: offices, 13: unused, 14-66: offices -> missleading key (one would expect a link to a level plan IMHO). Why should we suggest a key that is crying for multivalues? We don't use capital letters in key names (see beginners guide, 1.4.1). This could become: building:level:0:use=restaurant building:level:1:use=residential 7. building:levels:top=* The kind of top floor, if applicable. e.g. no/false/roof (standard), garden, gardens and roof gardens -> should/could be called "building:level:top" because the logics of "levels" is that of an amount of building levels. I am not sure how to best deal with this, maybe we should split up the page into several parts and start discussing on those more digestable units, to get some of them approved subsequently to have a better distinction between the first tagging ideas and the well discussed and reflected consensus suggestions. cheers, Martin _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
