3D Dächer mit Gauben

marek kleciak · 2011-10-01 10:22:49

In dem JOSM Plug in Kendzi3D wurde die Generierung der Gruppe 9 aus: http://wiki.openstreetmap.org/wiki/Roof_table implementiert.
Beispiel:

http://imageshack.us/photo/my-images/8/90aaaaa.png/

Die Multipolygon - inner werden noch nicht bedient.
Die Darstellung aller Gaubenformen funktioniert auch.

marek kleciak · 2011-10-02 17:23:03

Noch ein Beispiel aus der Gruppe 9

http://imageshack.us/photo/my-images/21 … aaaaa.png/

Tordanik · 2011-10-03 12:20:37

marek kleciak wrote:

Noch ein Beispiel aus der Gruppe 9
http://imageshack.us/photo/my-images/21 … aaaaa.png/

Nicht schlecht!

Dann sollte ich wohl auch mal von meinem aktuellen Stand berichten. Ich habe mittlerweile rudimentäre Unterstützung für Dächer-als-Geometrie nach Art der "Aschilli Roof Lines" (hier mal ein Screenshot) und bin gerade dabei, verschiedene Spielarten der Dächer-als-Tags umzusetzen. Sehr weit bin ich da noch nicht, bisher habe ich erst roof:shape=pyramidal (dein Type 2_5) und natürlich Flachdächer umgesetzt.

Irgendwie kommt es mir aber jetzt eher wie Zeitverschwendung vor, dass ich letztlich am selben Thema programmiere wie Kendzi.

marek kleciak · 2011-10-03 17:18:10

Hallo Tordanik,
tolle Arbeit, besten Dank für Deine Mühe. Die investierte Zeit ist nicht umsonst, es gibt Unterschiede, die beiden Ansätze notwendig machen.
Es ist schon der zweite Task, den ich vorbereiten muß, es ist aber interessant für alle User, denke ich.

Last edited by marek kleciak (2011-10-04 10:41:07)

marek kleciak · 2011-10-04 08:01:28

Gesagt, getan:

http://wiki.openstreetmap.org/wiki/DE:R … nvergleich

Ich muß dort noch einige Beispielsbilder hinzufügen, diese werden aber an den Aussagen nicht sehr viel ändern.

Viele Grüße,
Marek

dt2 · 2011-10-05 18:01:30

Ich habe ein paar Fragen/Anregungen zu Roof table:

Woher weiß man, in welcher Richtung das Dach liegt?
Die Dachgauben a-f scheinen alle bis zum Rand des Daches zu gehen. Was ist aber wenn ich einen Typ a habe, der aber wie Typ g etwas weiter hinten liegt? Die Gauben setzt man ja als Punkt auf den Rand des Daches, oder irre ich mich da?
Worauf bezieht sich die Prozentangabe bei den 3dr:length/heigth-Tags?
Ich glaube kaum, dass jeder mit einem Lasermessgerät durch die Gegend laufen wird. Kann man statt einer Meterangabe nicht auch die Anzahl der Stockwerke bis zum Dach angeben? Sicherlich ist das nicht unbedingt so genau, aber trotzdem sollte sich die Höhe so grob ausrechnen lassen.
Auf der Zeichnung von Typ 2_0 sind die Längen h1 und l1 angegeben. In der Tabellenzelle unter Typ 2_0 steht "H1, B1, B2". Entweder verstehe ich das nicht oder das passt nicht so ganz zusammen.
Bei den Dachgauben finde ich dormer=yes und dormer_type=* recht redundant. Man könnte doch auch bei dormer=* direkt den Typ angeben und für das "Das ist eine Gaube" nach dem Key "dormer" suchen, statt nach dem Tag "dormer=yes" (analog zu building=yes oder eben auch building=residential, building=garage, ..).
Den Tag 3dr:dormer=* verstehe ich nicht ganz. Ist das eine zusätzlich Möglichkeit zur Angabe neben dem Node im Rand der Fläche oder hängt das irgendwie damit zusammen?
Unter dem Abschnitt "Beispiel" könnte man annehmen, dass die Tabelle "Einfache Codierung der Dachbeschreibung" zu der Skizze darunter gehört. Offenbar ist das aber ein anderes Beispiel. Vielleicht könnte man das noch etwas klarer machen.

Gruß

Last edited by dt2 (2011-10-05 18:02:31)

marek kleciak · 2011-10-05 18:50:22

Hallo dt2,
super, ich freue mich über jede Anregung. Eines im Vorab: An dem Taggingsystem sollte weiter gearbeitet werden, daher finde ich Deine Aufmerksamkeit gut. Der momentane Taggingvorschlag stammt vom Kendzi - ich habe die Geometrietypen zusammengestellt sowie auf die notwendige Tags hingewiesen.

Also:
1. Ich machte beim Treffein in Garching den Vorschlag, dass man die Richtung in die man den Gebäudeumriss gezeichnet hat, zu diesem Zweck missbraucht. Die ersten beiden gezeichneten Punkte würden den Bezug liefern. Alternative ist, dass man 2 Punkte speziell kennzeichnet.

2. Alle Gauben können beliebig liegen. Auch wenn die Position auf der Gebäudeaußenkante am öftesten zu finden ist, gibt es mehr als genug Fälle, wo sie innerhalb der Dachfläche, sogar übereinander liegen ( z.B. hier: http://static.zoonar.de/img/www_reposit … 945c8.jpg)

3. Die Prozentangabe ist eine Idee von Kendzi: Wenn ich sage, dass eine Fassade eine Länge von 100% hat, dann kann ich bei der Angabe 20%, 40%, 60% gut und präzise drei Gauben platzieren, die echten Maße sind dann egal, nur das Verhältnis zählt. Um ehrlich zu sein, bin ich nicht ganz davon überzeugt. Man müsste praktisch feststellen, ob die Methode gut ist...

4. Das glaube ich auch. Lasermessgeräte sind zwar super, aber nur die wenigsten werden ein solches Gerät verwenden. Daher habe ich eine Tabelle mit Stockswerkhöhen zusammen gestellt:

http://wiki.openstreetmap.org/wiki/DE:O … b.C3.A4ude

Man kann bei vielen Fällen die Gebäudehöhe auch schätzen. Die Technik muss ich noch beschreiben. Die Ungenauigkeit liegt bei 5-8% der gesamten Strecke die zu messen ist.

5. Mein Fehler. Ich habe als Erstes die Parameter zusammen gestellt mit der Schreibweise auf Deutsch H- Höhe, B-Breite. Kendzi ergänzt nach und nach meine 3D Zeichnungen mit Parameter. Dabei hat er englische Schreibweise verwendet: h-height l-lenght. Ist natürlich besser, da internationaler. Die gesamte Tabelle muß ich noch also umschreiben. (Oder Du freundlicherweise )

6. Redundanz der Information: DEn Vorschlag finde ich sehr gut! Kannst Du die Seite dementsprecehnd modifizieren oder soll ich´s tun?

7. Ich muss Kendzi um eine genauere Beschreibung bitten. Diese ist in der Tat unverständlich.

8. Richtig, ich bearbeite diesen Abschnitt.

Danke nochmal dt2 und bitte um weitere Mitarbeit: Insbesondere wichtig wären Skizzen / Screenshots verschiedener Fälle aus der Praxis, damit wir sie gut einarbeiten können.

dt2 · 2011-10-05 19:41:41

marek kleciak wrote:

1. Ich machte beim Treffein in Garching den Vorschlag, dass man die Richtung in die man den Gebäudeumriss gezeichnet hat, zu diesem Zweck missbraucht. Die ersten beiden gezeichneten Punkte würden den Bezug liefern. Alternative ist, dass man 2 Punkte speziell kennzeichnet.

Kann man in den gängigen Editoren denn nach dem Zeichnen noch nachvollziehen, welcher Punkt der "Anfang" der Fläche ist? Die Richtung ist ja kein Problem (da gibt es ja die Pfeilchen), aber den entsprechenden Punkt sollte man wohl schon irgendwie kennzeichnen. Gerade weil man ja auch viele Dächer bei schon eingezeichneten Häusern ergänzen wird. Hat das "S" in manchen Zeichnungen auch damit zu tun?

marek kleciak wrote:

2. Alle Gauben können beliebig liegen. Auch wenn die Position auf der Gebäudeaußenkante am öftesten zu finden ist, gibt es mehr als genug Fälle, wo sie innerhalb der Dachfläche, sogar übereinander liegen ( z.B. hier: http://static.zoonar.de/img/www_reposit … 945c8.jpg)

Heißt das dann man setzt die Nodes an die entsprechenden Stellen oder gibt man das irgendwie mit Tags an? Da wäre ein Beispiel mit mehreren unterschiedlich gelegenen Gauben super.

marek kleciak wrote:

3. Die Prozentangabe ist eine Idee von Kendzi: Wenn ich sage, dass eine Fassade eine Länge von 100% hat, dann kann ich bei der Angabe 20%, 40%, 60% gut und präzise drei Gauben platzieren, die echten Maße sind dann egal, nur das Verhältnis zählt. Um ehrlich zu sein, bin ich nicht ganz davon überzeugt. Man müsste praktisch feststellen, ob die Methode gut ist...

Prozentangaben gibt es ja sowohl bei Höhen als auch Breiten. Bezieht sich das dann immer auf die Länge der Fassade oder auch die Höhe? Und auf die längere Seite oder auf die Seite an der man die Maße angibt? Bei Typ 2_0 und 3dr:length1=50% müsste sich das dann ja praktischerweise auf die entsprechende Fassade beziehen (damit der Giebel dann in der Mitte liegt).

marek kleciak · 2011-10-05 21:33:45

zu 1. Wieß nicht wie das in JOSM ist. In Potlatch muß man leider den Umris splitten (shortcut: x) um zu sehen, welcher Punkt der erste ist. Und ja das "S" auf der Zeichnung ist damit gemeint. Kendzi implementiert meine Idee, wir tauschen uns zwar aus, aber die Doku ist nicht perfekt, auch das muss man besser beschreiben...

Zu 2. Die Nodes sind dort, wo praktisch die Fensterscheibenebene der Gaube liegt. Die beliebige Lage der Gaube wird noch beim Rendern von Kendzi implementiert, Beispiele werden folgen.

Zu 3. Die Angaben beziehen sich für die Breiten und (noch) nicht für die Höhen, aber ich finde diese Idee gut und werde dies mit Kendzi besprechen. Das nette an der Prozentangabe ist eben, dass man bei Änderungen der Objektgröße trotzdem die im Verhältnis richtige Platzierung hätte... Die Angaben beziehen sich auf die Seite auf der man die Maße angibt.

dt2 · 2011-10-05 23:32:13

marek kleciak wrote:

4. Das glaube ich auch. Lasermessgeräte sind zwar super, aber nur die wenigsten werden ein solches Gerät verwenden. Daher habe ich eine Tabelle mit Stockswerkhöhen zusammen gestellt:
http://wiki.openstreetmap.org/wiki/DE:O … b.C3.A4ude

Dazu muss man sich auch noch das ein oder andere überlegen. Rechnet man die Höhe dann selbst aus und gibt sie als height=* an? Oder ist es nicht sinnvoller, die Stockwerke anzugeben, da so der Auswerter weiß, dass er nur schätzt. Sicherlich muss auch nicht jeder gemessene Höhe auf den Zentimeter (oder gar Meter) genau sein, trotzdem würde ich lieber das eintragen was ich auch erfasst habe.

Wenn man die Anzahl der Stockwerke einträgt (könnte natürlich auch sowieso interessant sein) muss man sich auch überlegen wie genau. Zum einen gibt es auch Stockwerke unter einem Schrägdach, die sollten wohl irgendwie seperat angegeben werden. Zum anderen gibt es teilweise Stockwerke die halb im Boden sind. Gibt man da dann z.B. levels=2.5 an? Oder doch lieber levels=2 für 2 "richtige" überirdische Stockwerke und height=2.5 levels für die Höhe bis zum Dach? Sollte man vielleicht generell auch "levels" als "Maßeinheit" akzeptieren? Wenn sowieso durch die Stockwerke die Höhe abgeschätzt wird, könnte man das auch direkt angeben.

Im Wiki gibt es Vorschläge für level-Tags. Aber auch da ist nicht wirklich klar, was mit Stockwerken unter einem Schrägdach passieren soll (die gibt es immerhin doch recht oft). Oder wie mit "halben Stockwerken" umgegangen werden soll. Genauso wie mir nicht ganz klar ist, ob height=* ("distance from ground to roof of the building") bis zum Beginn des Daches oder bis zum Giebel (falls Schrägdach) gehen soll. Bei der Roof table Definition ist das klar, aber ich bin mir nicht ganz sicher, ob andere das auch so nutzen.

marek kleciak wrote:

zu 1. Wieß nicht wie das in JOSM ist. In Potlatch muß man leider den Umris splitten (shortcut: x) um zu sehen, welcher Punkt der erste ist. Und ja das "S" auf der Zeichnung ist damit gemeint. Kendzi implementiert meine Idee, wir tauschen uns zwar aus, aber die Doku ist nicht perfekt, auch das muss man besser beschreiben...

Das "S" gibt es ja nur an einem Punkt. Schließe ich daraus, dass man auch in den Daten nur einen (Start-)Punkt benötigt, um die Lage festzulegen?

marek kleciak · 2011-10-06 06:22:00

Ja, nur 1 Punkt S ist erforderlich. Die Ausrichtung von dem Umriss gibt den Rest.

Zum Vorherigen im Laufe des Tages.

Last edited by marek kleciak (2011-10-06 06:23:00)

marek kleciak · 2011-10-06 14:30:21

Also, bei dem height=* haben wir auch die Möglichkeit source=* anzugeben, damit man weiß dass die Höhe z.B. "estimated" ist.

Viel wichtiger als eine exakte Einzelhöhe eines Hauses ist aber, dass die Höhen benachbarter Gebäude zueinander passen, damit sie ein plausibles Gesamtbild ergeben. Ich habe mit einer Studentengruppe der TU Hamburg ein 3D Stadtmodell untersucht: Selbst relativ geringe Höhenunterschiede in dem Geländemodell führen dazu, dass Gebäude, die eine Dachrinne in gleicher Höhe haben, auf einmal aus der Reihe tanzen. Das Ergebnis ist irritierend, daher ist ein Viewer / Modeller mit guter Usability so wichtig.

Die Anzahl der Stockwerke ist nicht nur relevant, sondern aus meiner Sicht ein Muß, wenn wir in Zukunft an Indoor Mapping denken wollen und z.B. Die Adressen der Firmen/Geschäfte geschoßweise angeben wollen.

Die Levels als Maßeinheit taugen zu nichts: wir haben für kommunale Modelle wo wir Nutzung und Geschoßigkeit exakt kannten, versucht automatisch Stadtmodelle zu erzeugen, indem wir die Anzahl der Geschosse mit einem Faktor dessen Wert sich aus der Nutzungsart ergeben hat multipliziert haben (Beispiel: Theater 1 Geschoss= 5 m). Die Ergebnisse waren schlecht und weit an der Realität vorbei. Wesentlich schlauer ist es eine Gebäudehöhe pro Straßenabschnitt zu messen und andere Höhen an diesem Gebäude orientieren, wobei die Ergebnisse gleich in einem 3D View überprüft werden müssen: Da sieht man sofort, dass man sich ggf. verschätzt hat und korrigiert die Hohe erneut.

Es gibt eine ziemlich aufwendige, aber exakte Methode für Höhenbestimmung unverputzter Gebäude: 3 Schichten Standardziegel inkl. Fugen haben genau 25cm Höhe. Hat man ein wiederholbares Geschoß fotografier und macht man sich die Mühe die Anzahl der Schichten einmal zu zählen, dan hat man eine fast zentimetergenaue Höhe.

Was die Anzahl der Stockwerke angeht, würde ich es als eine abstrakte, administrative Zahl lassen. Ein Übergeschoss ist dabei ein Stockwerk was mit mehr als der Hälfte der Höhe über dem Gelände liegt. Die Untergeschosse sind glaube ich schon mal in einem Proposal erwähnt?

Last edited by marek kleciak (2011-10-06 15:18:07)

Tordanik · 2011-10-06 16:52:34

marek kleciak wrote:

1. Ich machte beim Treffein in Garching den Vorschlag, dass man die Richtung in die man den Gebäudeumriss gezeichnet hat, zu diesem Zweck missbraucht. Die ersten beiden gezeichneten Punkte würden den Bezug liefern. Alternative ist, dass man 2 Punkte speziell kennzeichnet.

Und eine weitere dort genannte Alternative war, die Richtung des Dachfirsts oder eines anderen für die jeweilige Dachform markanten Elements als Tag am Gebäudeumriss (wo auch die anderen Tags, die die Dachform beschreiben, stehen) anzubringen. Denkbar wäre die Angabe der ungefähren Himmelsrichtung. Natürlich darf der Auswerter diese Angabe nicht für bare Münze nehmen, sondern sollte sich an den der angegebenen Richtung am ehesten entsprechenden Abschnitten des Hausumrisses orientieren.

Vorteil: Das bequeme Vergeben von mehreren Tags für ein Objekt wird bereits von aktuellen Editor-Vorlagen unterstützt und wird wegen der enormen Bedeutung für alle Themenbereiche von OSM auch in zukünftigen Editier-Tools am besten unterstützt werden. Wenn Teile der Information am Gebäude stehen, aber andererseits auch noch Nodes des Gebäudeumrisses oder dessen Zeichenrichtung eine besondere Rolle spielen, braucht man ein deutlich komplexeres Werkzeug speziell für diesen Anwendungsfall.

Ich habe jedenfalls vor, zu versuchen, wie weit ich mit dieser Methode komme.

dt2 · 2011-10-06 18:57:48

dt2 wrote:

Genauso wie mir nicht ganz klar ist, ob height=* ("distance from ground to roof of the building") bis zum Beginn des Daches oder bis zum Giebel (falls Schrägdach) gehen soll. Bei der Roof table Definition ist das klar, aber ich bin mir nicht ganz sicher, ob andere das auch so nutzen.

Das möchte ich nochmal ansprechen. Auf ProposedRoofLines ist das noch etwas eindeutiger formuliert:

There are mainly two tags available for estimating building heights, height=* and building:levels=*.
They measure the distance from ground to the roof top/ridge. What is missing is the height of the cullis. It can be either explicitly set by building:cullis:height=* or building:cullis:levels=*, or it can be calculated if other attributes are available, e.g. building:roof:height=* and building:roof:angle=*.

Soweit ich das richtig verstehe, nutzen also manche height=* als Höhe bis zum höchsten Punkt des Hauses (ohne Antenne o.ä.), während die 3DR-Definition von unten gesehen bis zum Beginn des Daches geht. Bei den Building attributes bin ich mir nicht ganz sicher, was gemeint ist:

"Approximate height - distance from ground to roof of the building (Roof, not antenna or spire for skyscrapers by default)"

Das sollte man unbedingt klären, gerade bei so einem allgemeinen Tag, der in unterschiedlichen Definitionen auftaucht.

Tordanik wrote:

marek kleciak wrote:
1. Ich machte beim Treffein in Garching den Vorschlag, dass man die Richtung in die man den Gebäudeumriss gezeichnet hat, zu diesem Zweck missbraucht. Die ersten beiden gezeichneten Punkte würden den Bezug liefern. Alternative ist, dass man 2 Punkte speziell kennzeichnet.
Und eine weitere dort genannte Alternative war, die Richtung des Dachfirsts oder eines anderen für die jeweilige Dachform markanten Elements als Tag am Gebäudeumriss (wo auch die anderen Tags, die die Dachform beschreiben, stehen) anzubringen. Denkbar wäre die Angabe der ungefähren Himmelsrichtung. Natürlich darf der Auswerter diese Angabe nicht für bare Münze nehmen, sondern sollte sich an den der angegebenen Richtung am ehesten entsprechenden Abschnitten des Hausumrisses orientieren.

Wenn das technisch funktioniert, wäre das sicher eine bessere Möglichkeit. Nur müsste man dann auf die Bilder statt dem "S" einen Pfeil zeichnen, der die Ausrichtung des Hauses angibt.

Last edited by dt2 (2011-10-06 19:02:47)

marek kleciak · 2011-10-06 19:43:29

dt2,
es stimmt: height=* ist bei der 3DR-Definition anders. Nach 17 Jahren in 3D Generierung der Stadtmodelle habe ich dafür zwei Gründe:

1. Rechtliche: Die Bauordnung (nicht nur in Deutschland und Polen sondern so ziemlich EU-Weit) definiert die Gebäudehöhe für Dächer zwischen 0° bis 45° Dachneigung (also bei den meisten) als die Differenz zwischen dem Gelände und der Verschneidungsebene der Hauptdachfläche und der Hauptebene der Fassade .Praktisch ist das die Höhe der Dachrinne. Bei Flachdächer ohne Dachrinne ist das Außenkante Dach. Dort ist die 3DR Definition der aus Building Attributes gleich.

2. Praktische:

2.1. Diese Höhe ist leicht zu messen von Straßenfotos (die Firsthöhen sind perspektivisch verzerrt, es sei denn man kann frontal auf die Giebelseite fotografieren) sowie
2.2. bei Stereofotogrammetrie für die Luftbildauswertung verwendet. Hat man also irgendwann in der Zukunft mit einem freien oder dem OSM verschenkten 3D Modell welches auf der Grundlage der meistverwendeten Stereofotogrammetrie erzeugt wurde, dann ist es die Höhen der Rinnen die in diesem Modell gemessen wurden.

2.3. Automatisierte Generalisierung bei dem Konzept Level Of Detail ohne den wir in Zukunft nicht auskommen werden (dazu muss ich noch Genaueres auf der OSM-4D Seite schreiben): Generalisiert man entferungsabhöngig Gebäude zu Quadern, dann bekommt man optisch bessere Ergebnisse wenn als Bezugshöhe die Rinne und nicht das höchste messbare Punkt eines Gebäudes genommen wird (Auch hier muss ich Beispiele einbauen)

Ich kann aber sehr gut verstehen, wenn jemand intuitiv versucht die Gebäudehöhe als die höchste messbare Höhe zu definieren. Es entspricht dem simplen Gedanken ein Volumenkörper durch einen Quader mit BxHxT zu beschreiben. Dass bringt aber Nachteile mit sich.

Um die Unterschiede zu vermeiden sollte man den Autor des Proposals building attributes um eine Änderung bitten ( ist das nicht ein Mitarbeiter von Herrn Zipf in der Uni Heidelberg?) Dass was dort als Höhe definiert ist kann einfach sinngemäß maximale Gebäudehöhe heißen heightmax=* oder so ähnlich...

Nochmal an dt2: Herzlichen Dank für Deine Arbeit und Aufmerksamkeit bei der Begriffsklärung.

Last edited by marek kleciak (2011-10-06 19:45:04)

Tordanik · 2011-10-08 21:26:05

Tordanik wrote:

Und eine weitere dort genannte Alternative war, die Richtung des Dachfirsts oder eines anderen für die jeweilige Dachform markanten Elements als Tag am Gebäudeumriss (wo auch die anderen Tags, die die Dachform beschreiben, stehen) anzubringen.
(...)
Ich habe jedenfalls vor, zu versuchen, wie weit ich mit dieser Methode komme.

Gesagt, getan. Hier ein paar übliche Dachformen, gerendert von OSM2World:

In der oberen Reihe wird jeweils nur ein einziges Dach-Tag pro Gebäude gesetzt (roof:shape = gabled/hipped/half-hipped/gambrel/mansard). Dann wird einfach die Richtung der längsten Gebäudeseite als Grundlage für die Platzierung des Firsts herangezogen.

Bei der Reihe darunter ist zusätzlich ein roof:ridge:direction = SW angegeben.

Die beiden separaten Gebäude (roof:shape = flat/pyramidal) haben sowieso keine Probleme mit der Richtung. Bei allen Dächern kann außerdem die Dachhöhe per Tag eingestellt werden. Einige wenige weitere Parameter, etwa die jeweiligen Abstände der beiden Firstenden zum Gebäuderand, wären leicht einzubauen.

Bei nicht-viereckigen Gebäuden sind meine Ergebnisse noch nicht wirklich gut. Zusätzliche Nodes z.B. für building=entrance verkraftet die Software ohne Schwierigkeiten, aber bei wirklich komplexeren Formen ist für meinen derzeitigen Ansatz die Grenze dessen, wo noch etwas Ansehnliches herauszuholen ist, schnell erreicht. Außer natürlich bei explizit gemappter Geometrie wie in meinem früheren Post, die alternativ unterstützt wird.

Nebenbei bemerkt: Alle im Post genannten Tags sind einfach nur Ideen und werden natürlich ggf. geändert, wenn wir uns auf etwas geeinigt haben. Ich habe mich aber schon einmal bemüht, sprechende Namen für die Dachformen zu suchen. Generell scheint das Tagging ja noch sehr diskussionsbedürftig zu sein, so verwende ich etwa auch noch die Definition "Boden bis Dachspitze" für height.

dt2 · 2011-10-08 21:54:32

Ist mir eigentlich auch relativ egal, wie die Höhe nun definiert ist, hauptsache sie ist eindeutig definiert. Wenn man mal bei Taginfo schaut, dann gibt es offenbar schon über 600.000 "height"-Tags in Verbindung mit einem Gebäude. Da stellt sich mir die Frage, wie viele davon nach welcher Definition getaggt sind und ob man die Definition überhaupt noch sinnvoll ändern kann. Gerade weil viele vielleicht intuitiv von der Gesamthöhe ausgehen.

Nun könnte man natürlich sagen: Wenn building:roof:shape=3dr am Gebäude steht, weiß man ja wie die Höhe gemeint ist. Allerdings werden andere Datennutzer das Tag vielleicht garnicht beachten und die Höhe als Gesamthöhe nehmen. Je nach Haus kann das Dach ja sogar mehr als die Hälfte der Höhe ausmachen.

Insgesamt eine nicht gerade zufriedenstellende Situation.

chris66 · 2011-10-08 22:20:06

Tordanik wrote:

In der oberen Reihe wird jeweils nur ein einziges Dach-Tag pro Gebäude gesetzt (roof:shape = gabled/hipped/half-hipped/gambrel/mansard).

Warum nicht building:roof:shape (24500 mal in DB) ?

Chris

Tordanik · 2011-10-08 22:47:58

chris66 wrote:

Tordanik wrote:
In der oberen Reihe wird jeweils nur ein einziges Dach-Tag pro Gebäude gesetzt (roof:shape = gabled/hipped/half-hipped/gambrel/mansard).
Warum nicht building:roof:shape (24500 mal in DB) ?

Weil bei diesem Schlüssel (und anderen, denn konsequenterweise müsste es dann ja auch building:roof:ridge:direction etc. heißen) die schiere Länge langsam unpraktisch wird. Leute, das muss noch in die Potlatch-/JOSM-Seitenspalte passen!

Außerdem: Manche der roof:-Tags werden nicht ans Gebäude selber gesetzt, sondern zumindest bei den Varianten mit expliziter Geometrie auch an Dachfirste oder andere Stellen des Dachs. Auch daher halte ich den building:-Präfix nicht für die beste Wahl.

Übrigens, bevor jemand auf die 17.000 "pitched"-Werte hinweist: Diesen Wert halte ich auf Grundlage der englischen Wikipedia-Seite für zu unscharf. Bei mir heißt das Satteldach derzeit "gabled". Da müsste man wohl mal die Muttersprachler fragen.

geri-oc · 2011-10-09 09:34:20

Tordanik wrote:

Gesagt, getan. Hier ein paar übliche Dachformen, gerendert von OSM2World:
http://tobias-knerr.de/upload/RoofGallery.png
In der oberen Reihe wird jeweils nur ein einziges Dach-Tag pro Gebäude gesetzt (roof:shape = gabled/hipped/half-hipped/gambrel/mansard). Dann wird einfach die Richtung der längsten Gebäudeseite als Grundlage für die Platzierung des Firsts herangezogen.
Bei der Reihe darunter ist zusätzlich ein roof:ridge:direction = SW angegeben.
Die beiden separaten Gebäude (roof:shape = flat/pyramidal) haben sowieso keine Probleme mit der Richtung. Bei allen Dächern kann außerdem die Dachhöhe per Tag eingestellt werden. Einige wenige weitere Parameter, etwa die jeweiligen Abstände der beiden Firstenden zum Gebäuderand, wären leicht einzubauen.
....

Ich finde die "Einfachheit" gut.

Wie wäre es, wenn man den Tag an eine gezeichnete "First"-Linie (nicht ans Gebäude) setzt und damit <roof:ridge:direction = SW> "einspart".
Dies liese sich auf Grund "der Linie-Einzeichnung" eventuell auch für <die jeweiligen Abstände der beiden Firstenden zum Gebäuderand> erweitern.

chris66 · 2011-10-09 11:37:55

Im buildings proposal wird das Tag building:roof:orientation=along/across vorgeschlagen. Ok, funktioniert nicht bei quadratischen Häusern.

Tordanik · 2011-10-09 21:33:07

geri-oc wrote:

Wie wäre es, wenn man den Tag an eine gezeichnete "First"-Linie (nicht ans Gebäude) setzt und damit <roof:ridge:direction = SW> "einspart".
Dies liese sich auf Grund "der Linie-Einzeichnung" eventuell auch für <die jeweiligen Abstände der beiden Firstenden zum Gebäuderand> erweitern

Du schlägst also eine Kombination aus der von mir schon länger implementierten Variante mit expliziter Geometrie einerseits und Dachform-Tags andererseits vor? Finde ich überlegenswert.

Im Gegensatz zum Linien-Zeichnen ist das Vergeben von Tags natürlich etwas, was man ebenso leicht in einem primitiven Editor (z.B. für Mobilgeräte ohne Maus) erledigen könnte, so dass die Hürde für die Erfassung vielleicht noch etwas geringer wäre, und die Copy&Paste-barkeit von Tags ist auch nett. Das Linienzeichnen richtet sich dann eher an den "Sesselmapper" mit Luftbildern, oder?

Zu klären wäre auch, wie man zwischen "ich habe die Dachgeometrie exakt und vollständig eingetragen" und "ich habe nur einen First als Richtungsangabe eingetragen, bitte vervollständige das Dach auf Basis des Dach-Tags" unterscheiden würde. Momentan schaue ich eben, ob irgendwelche Firstlinien o.ä. vorhanden sind - wenn ja, wird das Dach-Tagging am Gebäude ignoriert und stattdessen die von Hand gemalten Linien verwendet.

chris66 wrote:

Im buildings proposal wird das Tag building:roof:orientation=along/across vorgeschlagen. Ok, funktioniert nicht bei quadratischen Häusern.

Finde ich an sich sympathisch, da es noch ein bisschen einfacher ist. Leider geht es im allgemeinen Fall nicht, denn außer an den quadratischen Häusern wird es auch an Dachformen scheitern, die nicht symmetrisch genug sind. Da ist bei denen, die ich bisher implementiert habe, keine dabei, aber 1.0 und 2.2 aus der Roof type library wären gängige Beispiele, wo es halt doch mehr als 2 Möglichkeiten gibt.

geri-oc · 2011-10-10 09:34:07

Tordanik wrote:

... Das Linienzeichnen richtet sich dann eher an den "Sesselmapper" mit Luftbildern, oder? ...

Wie mappen denn "Nichtsesselmapper" Gebäude?
Vom Dach sieht man nur den Dachüberstand und an alle Hausecken kommt man auch nicht immer.

Ich mappe die Gebäude nach den Luftbildern und ergänze dann <addr>, <entrance> und <weitere> nach vor Ort.

Werde einmal einen Teil unseres Dorfes bei Gelegenheit einmal zum testen "ergänzen" (Linie mit tag)

marek kleciak · 2011-10-10 10:24:11

Hallo,
ich werde Freitag die Roof table um weitere Fälle ergänzen. Die Diskussion um quadratische Häuser ist insofern weniger relevant, als dass diese Fälle ziemlich selten auftreten. Viel wichtiger ist die Frage der Ausrichtung für Gebäude auf einem Grundiß der grob Buchstaben L, V, T, U, O, H ähnelt. Ich werde entsprechede (hand) Skizzen auf der Page platzieren. Der momentane Zustand der http://wiki.openstreetmap.org/wiki/DE:Roof_table ist noch alles andere als zufriedenstellend.

Ich babe über den Tag height=* nachdgedacht. Er solte doch noch lieber als Gesamthöhe eines Bauwerkes bleiben weil es schlichtweg intuitiv ist und die meisten Menschen eben so taggen würden ohne eine Spezifikation zu lesen. Ich habe auch mit Kendzi gesprochen: wir sollten die Definitionen so umkrempeln dass die beiden Seiten die es in Wiki gibt, kompatibel werden. Ich schreibe Freitag noch Einiges dazu.

viw · 2011-10-10 10:34:58

marek kleciak wrote:

Hallo,
ich werde Freitag die Roof table um weitere Fälle ergänzen. Die Diskussion um quadratische Häuser ist insofern weniger relevant, als dass diese Fälle ziemlich selten auftreten. Viel wichtiger ist die Frage der Ausrichtung für Gebäude auf einem Grundiß der grob Buchstaben L, V, T, U, O, H ähnelt. Ich werde entsprechede (hand) Skizzen auf der Page platzieren. Der momentane Zustand der http://wiki.openstreetmap.org/wiki/DE:Roof_table ist noch alles andere als zufriedenstellend.
Ich babe über den Tag height=* nachdgedacht. Er solte doch noch lieber als Gesamthöhe eines Bauwerkes bleiben weil es schlichtweg intuitiv ist und die meisten Menschen eben so taggen würden ohne eine Spezifikation zu lesen. Ich habe auch mit Kendzi gesprochen: wir sollten die Definitionen so umkrempeln dass die beiden Seiten die es in Wiki gibt, kompatibel werden. Ich schreibe Freitag noch Einiges dazu.

Wenn du an die Dachformen nochmal rangehst, wäre es schön eine Möglichkeit von Mischformen zu haben. Zum Beispiel dieses steile Satteldach und dann in ein Flachdach übergehend.

Announcement

#26 2011-10-01 10:22:49

Re: 3D Dächer mit Gauben

#27 2011-10-02 17:23:03

Re: 3D Dächer mit Gauben

#28 2011-10-03 12:20:37

Re: 3D Dächer mit Gauben

#29 2011-10-03 17:18:10

Re: 3D Dächer mit Gauben

#30 2011-10-04 08:01:28

Re: 3D Dächer mit Gauben

#31 2011-10-05 18:01:30

Re: 3D Dächer mit Gauben

#32 2011-10-05 18:50:22

Re: 3D Dächer mit Gauben

#33 2011-10-05 19:41:41

Re: 3D Dächer mit Gauben

#34 2011-10-05 21:33:45

Re: 3D Dächer mit Gauben

#35 2011-10-05 23:32:13

Re: 3D Dächer mit Gauben

#36 2011-10-06 06:22:00

Re: 3D Dächer mit Gauben

#37 2011-10-06 14:30:21

Re: 3D Dächer mit Gauben

#38 2011-10-06 16:52:34

Re: 3D Dächer mit Gauben

#39 2011-10-06 18:57:48

Re: 3D Dächer mit Gauben

#40 2011-10-06 19:43:29

Re: 3D Dächer mit Gauben

#41 2011-10-08 21:26:05

Re: 3D Dächer mit Gauben

#42 2011-10-08 21:54:32

Re: 3D Dächer mit Gauben

#43 2011-10-08 22:20:06

Re: 3D Dächer mit Gauben

#44 2011-10-08 22:47:58

Re: 3D Dächer mit Gauben

#45 2011-10-09 09:34:20

Re: 3D Dächer mit Gauben

#46 2011-10-09 11:37:55

Re: 3D Dächer mit Gauben

#47 2011-10-09 21:33:07

Re: 3D Dächer mit Gauben

#48 2011-10-10 09:34:07

Re: 3D Dächer mit Gauben

#49 2011-10-10 10:24:11

Re: 3D Dächer mit Gauben

#50 2011-10-10 10:34:58

Re: 3D Dächer mit Gauben

Board footer