[Tagging] building attributes

Martin Koppenhoefer dieterdreist at gmail.com
Wed Feb 8 12:40:50 GMT 2012


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



More information about the Tagging mailing list