Das gezeichnete Gebäude besteht aus zwei Rechtecken, die eine Kante zum Teil gemeinsam haben. Wenn ich diese Kante nur einmal zeichne, meckert die automatische Fehlererkennung, dass ein Areal nicht geschlossen ist. Wenn ich die Kante zwei mal zeichne (je einmal für jedes Rechteck), meckert sie, dass es doppelte Wege gibt.
Außerdem weiß ich nicht, ob ich alles, was ich an einem Gebäudeteil tagge, auch beim anderen eintragen soll (z. B. das name-Tag.)
Ich persönlich zeichne sie immer zweimal, da das andere die Renderer nur durcheinander bringt.
Ja das mit dem redundanten Taggen ärgert mich auch manchmal, wenn es zu hässlich aussieht lasse ich bei einem Teil den name tag einfach weg. Es gibt auch eine Site Relation um mehrere Gebäude zusammen zu fassen aber die wertet meines Wissens noch keiner aus.
wenn Dich das stört, kannst Du auch die zwei 3-seitige Ways und einen gemeinsamen Way einzeichen und beide Gebäude in je einer Relation zusammen fassen
Wie man sieht, wird das von mapnik-basierenden Renderern und osmar korrekt dargestellt.
Für ein einfaches Doppelhaus, wie in meinem Beispiel, halte ich das auch für übertrieben, aber die haben eine gute Lösung für wirklich komplexe Hausansammlungen gefunden, die imho formell sogar absolut ok ist.
Die Gebäude sind schon richtig gezeichnet, alles andere ist hier Overkill. Mit dem Tagging bin ich nicht zufrieden. Das doppelte name-Tag könntest Du alternativ auf einer Fläche für das Betriebsgelände unterbringen; alternativ könntest Du überlegen, die Gebäude zu einem zusammenzufassen. Ist halt die Frage, was der Realität näher kommt.
Was mich aber weitaus mehr stört, sind die doppelten power/generator-Tags. Wenn eines schönen Tages jemand eine OSM-Versorgungsinfrastruktur-Karte bastelt, findet er hier zwei Wasserkocher mit je 39 MW. Also entweder diese Tags nur an das Kesselhaus (vermutlich der westliche Teil) kleben oder alternativ einen separaten Knoten hineinlegen, der diese Information trägt. Auch bei den Adreßdaten kann man trefflich streiten, ob die doppelt vorhanden sein müssen. Ich vermute mal, daß (wenn überhaupt) nur an einem der Gebäude eine Hausnummer hängt.
Ok, die Zeichnung an sich werde ich so lassen. Die Häuser sind nunmal deutlich als zwei Blöcke voneinander zu unterscheiden, auch in der Höhe. Die Generator-Tags sind tatsächlich nur in einem Teil sinnvoll. Hausnummern und Adressen werde ich wohl an den vorderen Teil (von der Straße aus gesehen) klatschen.
Irgendwie hab ich jetzt ein Verständnisproblem, helf mir doch mal von der Leitung (auf der ich stehe…)
Wenn es doch zwei zusammenhängende Gebäude sind, die sich eine Wand teilen und zu einem “Komplex” gehören, warum willst du dann unbedingt zwei Einzelgebäude daraus machen?
weil man das nicht hinkriegt, ohne dass irgend ein validator “meckert”.
das geht rein topologisch nicht.
selbst die relation-lösung, die ich hier nur mal vorgestellt habe aber selber nicht verwende, ist nicht “motzfrei”.
daher mein Vorschlag: “Augen zu und durch”. Die Methode wird auch 6-Punkt-Verfahren genannt. Zwei geschlossene Wege mit einer gemeinsamen doppelt genutzten Trennwand.
Hallo Walter,
wenn ich mir die beiden Gebäude (und deren Beschriftung) mit dem o.g. Link anschaue, dann ist das für mich ein Gebäude das aus zwei Rechtecken besteht!? Ich “zeichne” solche Gebäude mit JOSM in der Art, dass ich zwei sich überlappende Rechtecke konstruiere, diese beiden Rechtecke mit gedrückter Umschalt- (Shift-Taste) markiere, danach Umschalt-Taste + J drücke und schon habe ich ein Gebäude.
Alles andere ist für mich Micromapping, wenn man anfängt jede Wand innerhalb eines Gebäudes zu mappen…?! Wer das mag ok, aber…
Georg
klar, so hast du genau EINEN way, der als geschlossene Linie das gesammte Gebäude beschreibt.
Aber:
Das gilt/galt es zu lösen. Zwei Gebäudeteile. Also brauchen wir mindestens zwei Ways. wie auch immer. Und alle hier aufgeführen Methoden haben ihre Nachteile, die “spanische” auch.
Das habe ich versucht, umzusetzen, zumal der westliche Teil seitlich versetzt ist (mit 6 Segmenten ist es also nicht getan) und 5-10 Meter höher als der andere.
