Gebäude, Parts, 3D, wie bekommt man alles richtig unter ienen Hut?

Communities Deutschland (Germany)
1

Hallo,

Tordanik hatte mir ja schon einmal bei dem Wildwuchs an 3D Varianten mit http://wiki.openstreetmap.org/wiki/DE:Simple_3D_Buildings geholfen. Nun ist das ganze aber doch ein wenig komplizierter und ich blicke hier langsam nicht mehr durch.

Ein Problem sind Gebäude die baulich gesehen eines darstellen und sich dennoch in einzelne Segmente teilen. Hier nehme ich mal wieder den guten alten industriellen DDR Wohnblock als Beispiel. Die wurden in ein einem Streifen hochgezogen, beinhalten aber einzelne Segmente, teilweise auch unterschiedliche. Dazu kommt, dass ich überlappenden Linien komplett aus den Weg gehen möchte, da ich aus der Praxis weiß, wenn alles drumherum dazu kommt und direkt anschließt, das ganze extrem suboptimal zu bearbeiten ist und sich schnell mal Fehler wie Überlappungen einschleichen. Also muss man es mit Multipolygonen lösen und die angrenzenden Wege aufteilen. Die Aufteilung wird sowieso nötig, weil sich manche Wegteile sowieso noch Informationen wie hedge, kerb etc. teilen müssen. Beispiele in der DB fand ich jetzt leider nicht, da fand ich leider nur die von mir nicht gewollte Überlappung.

Im Moment mache ich es noch so, dass ich für jedes Segment ein Multipolygon mit building=appartments anlege, an dem sämtliche Informationen von Adresse, bis Höhe und 3D Informationen hängen. So schaut das aus:

Nur irgendwie sagt mir da eine Stimme in Hinterkopf, unbefriedigend, bildet die Realität noch nicht sauber ab und könnte von manchen vielleicht nicht einmal richtig ausgewertet werden. Nun las ich da etwas von parts, type=building relationen usw. und blicke nicht richtig durch.

Nun hätte ich das ganze gerne so, dass es eine geschlossene Relation für die Gebäudehülle gibt, an der durchgehende Informationen wie Dachform, Farbe usw. hängen. Diese sollte wiederum die, in diesem Beispiel 4, Relationen mit den Parts umfassen, an denen zusätzliche Informationen des Segments, wie z.B. Adresse, Segmenttyp und damit Anzahl an Appartements, entrance oder auch abweichende Parameter bei Farben, Formern etc. hängen können, einschließt. So kann ich z.B. auch durch weglassen eines unteren Levels, in der Segment/Part Relation, eine weitere Relation mit einschließen, wenn im EG beispielsweise ein Geschäft oder Büro ist. Wie gesagt, lose Nodes, zig Überlappungen etc. finde ich äußerst unbefriedigend und haben jeweils wieder Nachteile.

Weiß jemand wie man das nun richtig umsetzt, oder gibt es sogar schon in der Form erfasste Beispiele, wo man sich mal ein Auge holen könnte?

2

Keiner eine Idee, gibt es da nichts?

3

Lieber Geokyf,
es ist schon richtig: 3D ist momentan eine Baustelle, aber da tut sich Was. Eine der Folgen der Meetings in Garching was, dass wir erkannt haben, dass eine gute, detaillierte Arbeit in 3D Bereich nur dann möglich ist, wenn ein 3D Editor geschrieben wird. Unsere Freunde aus Heidelberg haben darauf in einem Fachbeitrag in der Zeitschrift Geobit in diesem Sommer hingewiesen.

Seit knapp einem Jahr arbeiten Leute von der TU-Lodz an einem solchen Editor. Die ersten Ergebnisse haben wir bereits und ich hoffe man wird sie in diesem Winter testen können.

Sagt mir einer wie man eine Teilfinanzierung durch http://mapbox.com/blog/knight-invests-openstreetmap/ erreichen kann, wird es sicherlich schneller abgeschlossen - die Jungs müssen wie wir alle auch, Geld verdienen und das tun sie als Doktoranden indem Sie kleine Aufträge realisieren.

Soviel auf die Schnelle.

Beste Grüße,
Marek

4

Um 3D ging es mir jetzt nur nachrangig und zum Fundraising sage ich jetzt mal nichts weiter, sonst sehe ich den nächsten Shitstorm anrollen. Nur soviel, dass wenn man sowieso mit Spaß an der Sache dran ist, irgendwelche Gelder keine Rolle spielen sollten. Dauerts halt mal länger, sind wir doch aber gewohnt. Ich warte auch schon 4 Jahre darauf, das sich endlich mal einer der Speicherverschwendung in JOSM annimmt. Hat bisher keiner und dann wartet man halt weiter. Hier muss grundsätzlich keiner irgendwas, alles freiwillig. Natürlich ist so eine kleine Unterstützung immer schön, nur sollte die nicht im Vordergrund stehen. Ich möchte hier nicht den Tag erleben müssen, wo mich Steve Coast auf einem Banner anbettelt und das Gerede um versackte Spenden in aussichtslosen Projekten und dubiosen internen Geschichten losgeht. Die haben wir leider ja quasi aktuell schon.

Mir ging es erst einmal grundsätzlich darum, wie man z.B. eine Building Relation richtig nutzt. Ich habe 4 Gebäudeteile, die ein ganzes Gebäude darstellen. Das alles muss richtig in Relationen geschachtelt werden. Aktuell ist jedes Gebäudeteil ein Multipolygon, weil ich Mehrfachüberlappungen als suboptimal ansehe. Da suche ich Erfahrungen und/oder Beispiele, damit das auch richtig ist und ausgewertet werden kann. Wenn ich mir jetzt irgendwas ausdenke, nutzt das niemanden und wird schlimmstenfalls nicht ausgewertet. Bei OSM2World ist es bereits der Fall, da sind die bis dahin schon als Multipolygon umgesetzten Gebäude nicht existent. Entweder weil die Relationen nicht unterstützen, oder ich baue hier gerade riesen Bockmist und mappe für die Tonne. Um das herauszufinden und besser zu machen, muss man aber erst einmal wissen wie es richtig ist.

5

In einem anderen Thread hat Tordanik bestätigt, dass OSM2World nicht mit Multipolygonen umgehen kann, die aus mehreren outer-Elementen bestehen. Zur Sinnhaftigkeit solcher kunstvoller, mehrfach verschachtelter MP-Gebilde gäbe es viel zu streiten, aber du kannst dir auch einfach einen Thread wie den hier durchlesen. Welche Schlüsse du daraus ziehst, bleibt dir überlassen; möglicherweise kommt die Unterstützung für komplexe MPs in künftigen Programmversionen.

6

Da gibt es für mich nicht mehr viel zu streiten, weil Überlappungen schnell an Grenzen stoßen und ich damals auch dafür schon auf den Deckel bekommen habe. man kann es sowieso nicht allen recht machen. Wenn nur zwei Dinge aneinander grenzen geht das noch halbwegs, jedenfalls so lange, wie nicht beispielsweise eine Barriere auf einem Teilabschnitt beides abgrenzt und man zum MP gezwungen wird. Die Realität hat nun mal scharfe Grenzen. Wenn die Linie ein Zaun ist, links Wald und rechts Gras, ist das so. Irgendwelches erfundenes Nichts als Abstandshalter um die Bearbeitung zu erleichtern, bildet nicht die Realität ab. Das ist analog zum taggen für Renderer ein taggen zum Umschiffen von Editorproblemen oder fehlendem Wissen über MPs. Und bei Gebäuden ist das nicht anders. Da grenzt mal direkt eine andere Landnutzung etc. an, darauf vielleicht noch abschnittsweise ein Leisure, die Gebäudekannte an sich und vielleicht noch ein Part auf dem Gebäude oben drauf, schon sind wir bei 4 aufeinander liegenden Linien. Da empfinde ich eine Linie, die als Grenze von allen Beteiligten Elementen verwendet wird und auch noch selber eine Information wie eine z.B. Barriere tragen kann, deutlich angenehmer zu pflegen, als ein Stapel von zig Linien, den man bei jeder Bearbeitung auseinanderdröseln muss.

7

1+

Gruss
walter

8

Na das ist aber sehr kurz gedacht. Das mag für Verwaltungsgrenzen sicher noch sehr gut sein, aber stell dir mal vor wieviele Linien braucht es wenn du ein Gebäude wirklin seine Einzelheitn zerlegen willst. Dann besteht dein Umfang mit building=yes nicht mehr aus einer Linine, sondern aus vieren (für jede Seite eins) und um das ganze noch komplexer zu machen:
http://www.openstreetmap.org/?lat=51.003706&lon=13.79675&zoom=18&layers=M

Was meinst du wieviele Linien dann ein Gebäude ausmachen wenn jedes Treppenhaus extra einen Teilweg ist. Dann bekommst du auch noch je eine Relation dafür. Das ist doch auch nicht die Lösung oder?

Achso und dann sollen später mal noch Fenster Balkone und anderes ergänzt werden.

9

Wir müssen mit dem auskommen was wir haben und das sind im Moment eben nur geschlossene Flächen und Multipolygone. Wenn einerseits immer mehr Möglichkeiten zur Erfassung und Beschreibung von Details eingeführt werden, gleichzeitig aber Api und Editoren hinterher hinken, kann ich da als Mapper wenig tun. Was ich aber machen kann, ist aus dem vorhandenem das bestmögliche zu machen. Und das sind im Moment eben Multipolygone, die mit JOSM eigentlich relativ unkompliziert sind. Wo aber hingegen zig gestapelte Linien mehr Nachteile als Vorteile bringen.

Das fängt ja schon bei so etwas banalem wir kerb an. Fußwegfläche da, Straßenfläche dort, Bordstein mit unterschiedlichen Höhen, z.B. Senken für Rollis. Da haben wir ohne MP wieder 3 Linien übereinander und kerb sind sogar nur Stückchen, die vollständig auf der Linie liegen und nicht einmal einen Punkt zum anfassen haben. Per MP absulot simpel zu handhaben, als Linienstapel eine hübsch, hässliche Fummelei, bei der man so auch noch einiges versauen kann.

Das sollte jetzt aber eigentlich nicht die Grundsatzdiskussion werden und in meinem Fall spielt die Usability für Dritte noch keine so große Rolle, da ich das als einziger vor Ort pflege. Nur weiß ich jetzt noch immer nicht, wie man eine Building Relation richtig nutzt. Nutzt das wirklich absolut keiner, oder bin ich da mal wieder anders als die anderen?

10

Ich versuche mal, den aktuellen Stand darzustellen. Erst die Theorie:

Sowohl building als auch building:part sind Flächen (d.h. vor API-0.7 entweder geschlossene Ways oder Multipolygon-Relationen). Für jedes Gebäude muss eine building-Fläche existieren, die alle building:part-Flächen geometrisch komplett einschließt.

Das gilt auch bei Verwendung einer Building-Relation. Diese Relation existiert also zusätzlich zu den genannten Flächen und enthält sie als Mitglieder.

Bei einer Abbildung als geschlossene Ways sind diese direkt Mitglieder in der Relation. Wenn man Multipolygone verwendet, bekommt man verschachtelte Relationen: eine building-Relation, deren Mitglieder die Multipolygon-Relationen sind.

Die Praxis hält zwei maßgebliche Unterschiede zur Theorie bereit:

  1. Die Building-Relation ist ja fast immer redundant zum einschließenden building-Way (weil man die Zugehörigkeit zum Gesamtgebäude an der geometrischen Lage erkennt). Nur in Extremsituationen macht die Relation tatsächlich einen Unterschied, nämlich bei sich im Zweidimensionalen überlappenden Gebäuden. Und da die Building-Relation auch in der Mappingpraxis nicht angekommen ist, hatte das Einbauen für mich bislang keine hohe Priorität. OSM2World - und meines Wissens auch Kendzi3D - ignorieren sie daher völlig und ordnen die building:part dem building weiterhin über die Lage zu. Das sollte bei den meisten Gebäuden allerdings keinen Unterschied machen.

  2. Unterstützung für “advanced” Multipolygons - also solche mit mehreren, nicht geschlossenen outer-Ways - ist bei den ganzen 3D-Clients noch nicht eingebaut. Eigentlich sollten geschlossene Ways und MP semantisch gleichwertig sein und die Entscheidung für eine Form der Darstellung danach getroffen werden, was sich einfacher pflegen lässt. Heute führt die Multipolygon-Darstellung aber wegen der fehlenden Fähigkeiten der Programme noch dazu, dass ein so gemapptes Gebäude in den betroffenen 3D-Darstellungen gar nicht auftaucht. (Und übrigens auch manche Seen oder Wälder fehlen, wo diese Multipolygone ja verbreiteter sind als bei Gebäuden.)

Na ja, eine als eigene Linie eingezeichnete Bordsteinkante ist nicht unbedingt “banal”. :wink: Das würde ich eher als extrem genaues Mapping sehen, das dem normalen Stand unserer Daten um Jahre voraus ist. Ich bin eigentlich froh, wenn es mancherorts zumindest sidewalk-Tags an den Straßen gibt.

11

Also so wie ich es verstanden habe, sieht der Fahrplan jetzt so aus. Bei den MP mit den Parts die momentan noch einzeln als building=appartment getaggt sind und die Adresse, vom Gesamtgebäude abweichende Parameter wie andere Dachfarbe usw. beinhalten, tagge ich diese jetzt nur auf building:part um und änderte den type in building. Dort kann ich die Rollen für z.B. entrance vergeben. Die Rolle Adresse entfällt, die ist Eigenschaft des ganzen Parts bzw. Gebäudeteils und kommt somit direkt an die Relation. Diese, im obigen Beispiel 4, fasse ich einfach in der Building Relation zusammen, zusätzlich alle Linien des Gesamtumrisses, welche dann die Rolle Outline bekommen?

Kommt das so hin? Das es die 3D Renderer momentan nicht unterstützen ist nicht das Problem, ich will es nur technisch so sauber wie möglich umsetzen, so das es überhaupt irgendwo ausgewertet werden kann.

Das mit den Sidewalks etc. hatte ich schon von Anfang an drin. Nur mittlerweile gibt es soviel mehr womit man die Realität wirklich beschreiben kann und da sind ständig Situationen, die man auf einer Linie nicht beschreiben kann, oder wo man diese praktisch atomisieren muss. Aus diesem Grund habe ich nun angefangen, zusätzlich zur Linie die area:highway zu nutzen, mit allem was so dazwischen liegt usw. und da bietet sich dann auch die genaue Erfassung von eben Kerb an. Das ist an einer Linie nur schwer bis gar nicht zu beschreiben. Das mag im Moment alles noch weit in der Zukunft liegen, nur hatte ich die nötigen Daten sowieso schon immer liegen und mit den neuen Luftbildern nun auch die nötige Grundlage es nach unseren bescheidenen Möglichkeiten umzusetzen. Solange es parallel noch das bisher übliche Schema in den Daten gibt und sich nicht damit beißt, sollte das auch kein Problem sein. Hier hat doch so ziemlich jeder seine Testballons in den Daten, so wie Passau für 3D. Sollte sich das nie durchsetzen und wir bleiben bis auf ewig einzig bei Wegen, hat es wenigstens Spaß gemacht.

Und ich nehme es sehr genau, wenn möglich so weit ans Kataster heran wie es geht. Nicht aus Langeweile, sondern weil die hier wie die Könige auf ihren amtlichen Daten hocken, OSM ignorieren und ich denen eine lange Nase zeigen will. Sollen die mit ihren tollen iphone Karten glücklich werden, wir können das besser. :wink:

12

Ich bin mir nicht ganz sicher, ob ich richtig verstehe, was du hier beschreibst.

Die type=building-Relation ersetzt nach dem dokumentierten Tagging nicht das building-Polygon. Wenn du mit komplexen Multipolygon-Relationen arbeitest, hättest du also davon eine für jedes Teilgebäude (mit type=multipolygon und building:part=) und eine für das Gesamtgebäude (mit type=multipolygon und building=).

Obendrauf könnte noch eine building-Relation kommen, mit den genanten MP-Relationen als Member und ggf. noch Dingen wie Eingängen. Letztere sollten unabhängig davon natürlich auch als entrance getaggt und Teil der Ways sein.

13

So geht es theoretisch natürlich auch. Wenn ich nicht ganz denn Sinn verstehe, warum man das Gesamtgebäude MP nicht gleich direkt durch die Building Relation ersetzen kann. Eine unschöne Doppelung. Ich habe das jetzt mal testweise so geschachtelt (für die schnelle Rolle Rückwärts sind die Einzellinfos noch in den Parts belassen).

Die Building Relation: http://www.openstreetmap.org/browse/relation/2430848
Das Gesamtgebäude MP: http://www.openstreetmap.org/browse/relation/2430847
MP Segment 1: http://www.openstreetmap.org/browse/relation/2413815
MP Segment 2: http://www.openstreetmap.org/browse/relation/2413821
MP Segment 3: http://www.openstreetmap.org/browse/relation/2413822
MP Segment 4: http://www.openstreetmap.org/browse/relation/2413818

In JOSM sieht man so nun natürlich keine Hausnummer mehr, kein Problem. Auf Mapnik scheint auch alles schick zu sein http://osm.org/go/0MBdFm_ul–, inwieweit andere damit klar kommen, bei der mittlerweile angebotenen Masse an Programmen und Karten kaum überprüfbar.

Jetzt kommt jedoch das große Aber. In der Building Relation sind ja die Eingänge als Rollen zu benennen, soweit noch machbar da sowieso extra vorhanden. Wobei mir nicht ganz klar ist, wie das in der Auswertung dann dem jeweiligen Segment zugeordnet, geschweige denn mit der zugehörigen Adresse in Verbindung gebracht werden soll, wenn da keine Beziehung zueinander beschrieben wird. Ich habe nun keine Ahnung von den Anwendungen, können die vielleicht automatisch, man weiß es nicht.

Nur habe ich nun ein riesen Problem. Die Adresse kann ich gar nicht als Rolle angeben, da diese ja Teil des jeweiligen Segments sind und dementsprechend im Segment MP sind. Könnte man nun natürlich wieder als einen extra Node an der Hauswand umsetzen, wäre aber wiederum ein Rückschritt. Denn auch wenn sich das Gerücht hartnäckig hält, eine Hausnummer ist nicht nur ein Schild an der Wand, es ist bei Häusern mit eigenem Grundstück eine Eigenschaft des ganzen Grundstücks, bei OSM entspräche das in etwas einer Site, kann ich das nicht eingrenzen, dann des Hauses. In diesem Fall, aufgeteiltes Gebäude welches gesamt auf einem Grundstück steht, ist es die Eigenschaft eines Gebäudeteils. Offizielle Info vom Bauamt und dürfte bundesweit gelten. Und das dürfte jedem spätestens auch dann klar werden, wenn man auf die ersten Häuser trifft, wo die Nummer irgendwo vorne am Tor oder Zaun hängt und in der somit auch nicht in der Realität einen Punkt an der Hauswand darstellt.

Was mache ich nun? Diese halbgare Lösung weiter verfolgen, der ich jetzt nicht wirklich vertraue, oder ich belasse es so wie es vorher war und warte auf etwas wirklich ausgereiftes?

Edit: Noch eine Ergänzung zur Hausnummer, weil da öfters mal der Einwand der Darstellung in Katastern etc. kam. Dafür wäre hier analog das Label zuständig. Also die Nummer an sich ist die Eigenschaft des Grundstücks, Gebäudes oder Gebäudeteil und kann mit Label nach belieben dargestellt werden. Das wäre dann eben z.B. ein Node neben dem Eingang oder vorne am Tor vor dem Haus.