I usually go for a mixture of 1.1. and 1.3., i.e.
- use building:part for the architectural blocks the building is made of,
with building:min_height / building:min_level where appropiate
- use type=multipolygon building=*, stuff the usual building tags into that,
this will be rendered by non-aware 3d renderers, i.e. serves backward compat
and will be added in role outline to the following
- use type=building relation to group together outline and parts,
see http://wiki.openstreetmap.org/wiki/Relation:building
(though I've never used ridge or edge roles)
See http://www.openstreetmap.org/relation/2436669
for an example that deals with the exact same problem you
describe (level 2 having larger extents than ground level).
As for your point 2. - afair simple buildings allows to define
roofs only along with building:part, so there is no extra
mechanism to define roof elements separated from those.
If you have a roof that deviates a lot from the building
parts it covers (or you want to define the roof as a single
object covering a lot of building parts), you can "hack"
around the proposal's limitation by using extra building
parts for the roof elements in question (or single roof)
that lack a building level and only account for the resp.
roof levels.
In part this method can be challenged by "we do not
tag for renderers" principle, but there is no other
alternative for in-db 3d building mapping that I
know of (and that is as widely used as the simple
building proposal).
Most frequent you will be tempted to use this "hack"
for full building connectors (not skyways that are
limited to a subset of stories/levels):
If you have a hipped roof on the main building parts
and a gabled one covering the connector part and
their roofs are at same height, the roof outline of
the connector will overlap that of the levels below.
There are two solutions to this:
- model connector's roof separately (i.e. using
two building:part relations
- extend the outline of the connector as a whole
into the main building parts it connects
For the first solution you could argue: "but it's only
one building part not two, and if the levels below are
mapped separately a flat roof will be silently assumed,
where a gabled one is attached, but modeled separately"
For the second solution you might get problems with
indoor mappers in time.
Both are to some degree "quick and dirty", but then
that may be true for the whole simple building proposal.
It's acclaimed to be 'simple' for a reason and does not
account for some of the specialities in architecture
you'll find out there.
IMO this is a good thing, because this also limits data
size (it naturally deflates real data, because mappers
go for the most dominant parts of a building and do
not loose themselves in details). For feature-rich
buildings with lot of small detail that is hard to
capture with the simple buildings proposal, you
could still go for an external model, store the data
elsewhere and mash it, like f4-map does.
Greetings
Gesendet: Donnerstag, 02. März 2017 um 14:09 Uhr
Von: "Martin Koppenhoefer" <[email protected]>
An: "Tag discussion, strategy and related tools" <[email protected]>
Betreff: [Tagging] how to map simple buildings
Von: "Martin Koppenhoefer" <[email protected]>
An: "Tag discussion, strategy and related tools" <[email protected]>
Betreff: [Tagging] how to map simple buildings
I have just started mapping according to the simple building scheme and have some questions to the more experienced mappers:
A situation I meet very often are buildings consisting in several parts, e.g. often there are higher parts on the (flat) roof that are smaller than the rest.
1. Which representation do you deem preferable:
1.1. map the largest horizontal building extension (e.g. building:levels=5) and add on top a building:part with building:min_level=5, building:levels=1
1.2. map a polygon for only the part that has building:levels=5 leaving out the higher part and add this higher part as building:levels=6 (no min_level here).
1.3. Do you map these as building:part=* and add a third object (in the simplest case) for the building with building=* to combine them? Do you prefer the third object to be a relation or a closed way, and do you add building:level tags as a fallback to it?
2. What is the "roof"? E.g. in the context of flat roofs which are inhabited (apartments, terraces, etc.)
2.1. is this part of the "roof" and the level should not be counted in building:levels (IMHO it is part of the roof):
http://www.dach1.at/wp-content/uploads/sl_dach.jpg
http://www.dach1.at/wp-content/uploads/sl_dach.jpg
2.2 but if 2.1 is part of the "roof", shouldn't this also be 2+1 levels rather than 3?
http://media.getrix.it/1/5544/2488638989.jpg
http://media.getrix.it/1/5544/2488638989.jpg
2.3 similarly, is this 5+1 or 6 levels?
https://imganuncios.mitula.net/casa_di_200_mq_a_collina_fleming_vigna_clara_roma_4010133485552255323.jpg
https://imganuncios.mitula.net/casa_di_200_mq_a_collina_fleming_vigna_clara_roma_4010133485552255323.jpg
2.4 there are also cases where inclined tiles have been applicated later to prefabricated houses with flat roofs to make them look more similar to traditional houses. Inside the house has remained the same, but from the street it now looks as if there was kind of inclined roof.
3. Am I right that this is not representable with the simple building model?
(It's a rotated roof, not parallel with the building sides)
Thank you,
Martin
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
