Was die Datenerfassung anheht, habe ich auch lustige Geschichten auf Lager: Ich habe die 3D Ländmarks mit einem 3D Scanner (LMS-Z210, siehe www.riegl.com ) erfasst: 15kg Eigengewicht, 2 Autoakkus angeschlossen, Holzstativ 2m Hohe, Laptop, Kamera, GPS drauf alles verkabelt. Es sah aus wie eine mini Atombombe die ich eben in die Luft jagen möchte… Niemand hat reagiert: in gaaanz Deutschland. Bis auf 2 Ausnahmen auf 2000 Objekte: Jüdisches Museum in Berlin. Ich und mein Kollege wurden beinahe erschossen bevor wir mit dem Ding aus dem Auto ausgestiegen sind. Kurz nach dem 11 september 2001 haben wir ein Hochhaus vermessen. Man hat das Gebäude beinahe evakuiert, als man uns sah…
Einige Leute waren neugierig aber freundlich, deshalb hatten wir immer einige A4 Zettel mit einer Beschreibung was die neue 3D Scantechnik so alles kann.
Ich denke, dass wenn man den Menshcen erzählt, was man macht, werden viele auch freundlicher. Für die anderen hatten wir ein Schreiben von dem Bundesdatenbeauftragten in dem stand dass das was wir tun, zulässig ist. Und im Zweifelsfall kann man das auch der fragenden Polizei erzählen: Jegliche Art der Datenerhebung die von dem öffentlich zugänglichen Grund ohne Behinderung der öffentlichen Ordnung durchgeführt wird, ist nach geltendem Recht zulässig!
Und die Lasermessgeräte der Baumarktklasse sind gesundheitsunbedenklich - solange man sich dieses hübsche, rote Licht nicht direkt anschaut…
Ein Hinweis: Messung der Fassadenhöhe bis Dachrinne ist einfach, aber nicht bei grellem Tageslicht! Am besten am späten Nachmittag bis Abend messen: man muß den Messpunkt sehen!
irgendwelche buildings mit Beispiels-Dächern halt. Ich wollte mir nur mal das Tagging in OSM ansehen. Kann aber sein, dass alles im wiki drinsteht - nur hab ich das nur sehr kurz überflogen.
Hallo Walter,
die Beispiele muß ich noch einbauen - übrigens - gute Idee. Ich gebe aber zu: der momentane Taggingvorschlag ist noch nicht ausgereift. Ich hoffe auf Gegenvorschläge.
Wenn ich das richtig verstanden habe, willst du alles in OSM speichern, ohne Referenzen auf eine externe Datenbank für komplizierte Objekte.
Die komplizierteren Gebäude sollen dann aus Teilobjekten die mit Relationen zusammengefaßt wurden, dargestellt werden, wobei das ja auch nur bis zu bestimmten Grenzen möglich ist. Anderrseits nimmt ja auch die Abbildung von nicht zum Objekte gehörenden Sachen zu, je mehr Detail man in OSM umsetzt. Wenn z.B. auch die Fensterbänke modelliert werden, muß man dann auch evtl. darauf befindliche Blumentöpfe erkennen und entfernen können. Ein Problem wird da sicher auch die automatische Übertragung von gescanten/erfassten 3D-Körpern in die zugehörigen OSM-Objekte, da muß der Computer ja die reale Bedeutung der Klötzchen kennen. Gut, es würde ja auch schon reichen, wenn man die 40% der simplen Häuser automatisch generieren könnte.
Aus meiner Sicht brauche ich da nicht mehr all zu viel weiter zu machen, weil man kann ja aus Gebäudefotos schon offenbar recht gute Modelle erzeugen, wohingegen das aus Orthofotos, wegen der mangelnden Information über den Dachunterbau eher schwer ist. Da wäre es eher hilfreich wenn sich fähige Leute finden, die versuchen eine Lösung zur Fotoerkennung zu basteln, denn das würde in Anbetracht der vielen Fotomapper und auch der Videomapper, die z.B. wegen Hausnummern, die Häuser ja eh schon aufnehmen, sicher recht viel bringen.
Hallo Fabi,
die Idee in OSM Referenzen auf hochkomplexe 3D Objekte zu speichern ist sicherlich nicht schlecht und sollte ausprobiert werden. Bei Punktwolken (falls sie vorliegen) wird in dem “neuen” 3D Editor der User entscheiden welche Bedeutung die aus Punktwolken gewonnene Flächen haben.
Es gibt noch keine zufirieden stellende Lösung für die automatische Modellierung für Dachunterbau. Ich möchte eine Funtion vorsehen in der der User die “Dachstärke” sowie Versatz für jede einzelne Wand angeben kann: Somit hätte man zunächst eine grobe Lösung.
An der “guten” Lösung arbeite ich mit einigen Usern.
Kendzi hat einige Beispiele für Gebäude die mit dem beschriebenen Ansatz modelliert sind. Zu finden sind sie ab hier:
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.
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.
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.
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:
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.
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…
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:
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.
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 )
Redundanz der Information: DEn Vorschlag finde ich sehr gut! Kannst Du die Seite dementsprecehnd modifizieren oder soll ich´s tun?
Ich muss Kendzi um eine genauere Beschreibung bitten. Diese ist in der Tat unverständlich.
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.
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?
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.
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).
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.
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.
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?
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?
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.
Das möchte ich nochmal ansprechen. Auf ProposedRoofLines ist das noch etwas eindeutiger formuliert:
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:
Das sollte man unbedingt klären, gerade bei so einem allgemeinen Tag, der in unterschiedlichen Definitionen auftaucht.
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.
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:
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.
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.
)
