S3DB. Horizontale streifen verschiedener Farbe füe ein Bauwerk

wir haben des Ofteren ein Problem mit einem Gebäude in dem horizontale Streifen auftreten.
Oft hat Erdgeschoß und Obergeschoß eine andere Farbe.
Was tun?

Ich schlage folgende Lösung vor:

http://wiki.openstreetmap.org/wiki/S3DB_Proposals#Horizontal_colour_changes

Vielleicht kriegt man das aber auch schlauer hin…
Grüße,
Marek

Hallo Marek,

Ich stecke zwar nicht besonders tief in den ganzen 3D- und Indoor-Sachen drin, aber ich persönlich finde diesen Vorschlag nicht gut. Wenn es eine nahezu unbegrenzte Zahl an Keys gibt, erschwert das die Auswertung (v.a. den Import in Datenbanksysteme). Warum orientierst du dich nicht an den Conditional Restrictions? Dein Beispielgebäude würde ich dann wie folgt taggen:

building:colour=#ffd05c (als Fallback für einfache Renderer)
building:colour:vertical=#d7d559c @ (0.00-2.10); #8d8a5d @ (2.10-4.25); #ffd05c @ (4.25-8.70); #8d8a5d @ (8.70-11.50); #d7d559c @ (11.50-12.50)

Ich würde vertical statt horizontal verwenden, da sich die Farbe in Lotrichtung ändert. (siehe auch meine Hirngespinste weiter unten)

Das könnte man dann gleich ausbauen zu einem Conditional-Building-Schema. Wie wär’s mit

  • … unterschiedlich steilen Dächern: roof:angle:conditional=45° @ (0,00-2,00); 30° @ (2,00-5,00)
    Diese Höhen wären dann aber lotrecht und nicht entlang der Dachhaut (Ziegel-/Blechoberfläche) gemessen, wobei 0,00=Dachtraufe=Schnittpunkt Wand mit Dachhaut

  • … Gebäudennutzung geschossweise eintragen für Auswerter, die nicht gleich volles Indoormapping auswerten wollen: building:vertical=retail @ (level=0); residential @ (level=1-3); storage @ (level=4)

Viele Grüße

Michael

Hallo Michale,
danke für Deine Stimme!
Was sagen die Anderen dazu?

Viele Grüße,
Marek

Das eigentliche Problem ist aber: Ein Haus ist in den seltensten Fällen “rundherum” gleich gebaut oder gar gleich angemalt.
Grundsätzlich könnte man schon solche horizontalen Farbstreifen auch in S3DB mit einem Farbtag versehen, aufgeteilt in Höhe nach Mareks Vorschlag oder level-Bereiche.
Die Höhen sind aber, ohne “Maß zu nehmen” so genau gar nicht von außen augenscheinlich meßbar, bestenfalls die untersten Stockwerke. Deshalb sollte auch level Angabe möglich sein.
Also einfacher Fall: 3 Stockwerke:
building:colour:horizontal(:level 0)(:1)=#d7d559c ( |0.0-2.5 )
building:colour:horizontal(:level 1-2)(:2)=#8d8a5d ( |2.5-7.5 )

Schwierig wird es, wenn man jetzt z.B. nur die Nord- und die Südwand mit Streifen vorfindet.
In S3DB hat man i.d.R. nur ein building-way. Ohne jetzt kompliziertere building:parts erstellen zu müssen, wie wär’s damit:
building:colour:horizontal:level 0:north=#d7d559c
building:colour:horizontal:level 0:south=#d7d559c
building:colour:horizontal:level 1-2:north=#8d8a5d
building:colour:horizontal:level 1-2:south=#8d8a5d
building:colour:(level 0-2):west=#8d8a5d
building:colour:(level 0-2):east=#8d8a5d

Wobei Himmelsrichtung natürlich auch abkürzbar zulässig sein könnte: n / e / s / w … nw / se / ne / sw

Noch komplexere Hausbemalungen wie http://wiki.openstreetmap.org/wiki/File:AkademicheskiyRyabinina25.jpg
sind so dann wohl so nicht mehr möglich.

Die Conditional Restrictions - Methode ist auch ok. Hier verliert sich aber IMHO die Übersichtlichkeit. Wichtiger scheint mir hier, die Außenwände “einzeln” zu betrachten.

Grüße,
Rolf

Man kann Hausfarben nicht wirklich als Eigenschaft des Gebäudeteils verwenden, wenn es bunt wird. Schau dir als einfaches Beispiel mal die Häuser in Nürnberg, Schöpfstraße (insbesondere die Nordseite) an. Da klebe ich >vielleicht< mal ein Bild dran - aber beschreibe das nie mit Konditionen. Bei den Gebäuden mit übersichtlicher Farbgebung kann man das noch mit Parts abdecken - pflegbar bei einem Neuanstrich mit einem anderen Muster ist das aber nicht. Hier (http://demo.f4map.com/#lat=49.4510699&lon=11.1045334&zoom=19&camera.theta=56.173&camera.phi=-140.948) würde ich aber auch dringend vor dieser Methode abraten, weil man da ca. 50 waagerechte Elemente aufgeteilt in diverse vertikale Blöcke erhalten würde. Die Einteilung in N/E/S/W funktioniert ansonsten auch nur bei sehr einfach strukturierten Objekten.

Das 3D-Modelling stößt schon lange an seine Grenzen, auch einem ‘Full 3D’ Schema wird es so ergehen. Diese Thema hier mit den horizontalen Streifen ist ein schönes Beispiel dafür.
Weil hier auf einer zweidimensionalen Fläche versucht wird, mit abstraktem Tagging 3D abzubilden.

OSM bräuchte ‘echte’ 3D Objekte, mit einem entsprechenden Editor zum modellieren.

+1
Danke. Der Meinung bin ich auch :wink:

Hallo,

Ich auch.

Aber hier eine neue Überlegung. Das Indoortagging im F3DB oder S3DB verwendet ja den tag indoor:wall=yes o.ä. …
Da man hier sowieso lines übereinanderlegen muss, was ist mit der Außenwand des Gebäudes? Das ist keine indoor wall. Sondern die outer wall (outdoor:wall=yes).
Ich finde nirgendwo eine solche Beschreibung. Natürlich wäre das eine 2 Linie auf dem building oder dem building:part. Halt die Außenmauer.
Und diese läßt sich doch building:level-weise durchaus doch durch “Außenfassaden” taggen, oder nicht?
Bevor ich hier mehr ins Detail überlege, die Frage, ob eine Zusatzlinie tag outdoor:wall=yes ( auch im S3DB bei einfachen Gebäuden ) Sinn macht?
Jede Außenmauer hätte dann seine eigene line.

Vielleicht etwas “krumm” gedacht, aber das wäre IMHO auch eine Möglichkeit, das Fassadentagging zu etablieren.

NG Rolf

Da habe ich Zweifel, ob da OSM (bzw. sein Datenmodell) nicht hoffnungslos überfordert ist. Nicht umsonst gibt es für die 3D-Modellierung eigene Formate (VRML o.ä.) und spezielle Werkzeuge.
OSM2World und F4 sind ja nett anzusehen, aber lieber als ein Gebäude in voller Farbenpracht wäre mir, wenn die Gebäude in der Umgebung wenigstens Straße und Hausnummer hätten, vom größten Teil der Welt erst gar nicht zu reden.
Ich habe nichts dagegen, wenn sich jemand intensiv mit 3D beschäftigen möchte, die Datenbank sollte aber nicht zu sehr mit immer neuen Schemata überladen werden.

Da magst du Recht haben, und im Endeffekt meinen wir wahrscheinlich das gleiche.

Um 3D in der Form abzubilden, wie es einige hier gerne hätten, bräuchte man evt. eine parallele Datenbank für das 3D-Modelling, wie auch immer das technisch umzusetzen wäre…

Jeder ‘Anti-3Dler’ kriegt doch heute ne Macke, wenn er sich einen Ausschnitt in JOSM herunterlädt, und manch einzelnes Haus besteht aus mehr Daten (Nodes, Tags, Relationen(!)), als der Rest vom Ort.

Ja, und Speicherung außerhalb der OSM DB (die dafür einfach nicht geeignet und designiert ist).
Chris

Was wird das denn jetzt? Eine Demontage jeglicher 3D und Indoor Ambitionen von alt renommierten und sehr engagierten OSM Vorbringern?

Ich sag jetzt nix mehr dazu. Wenn 3D und Indoor nicht gewünscht wird, dann hätten sich die Kollegen ja schon mal früher melden sollen.

Allerdings vermisse ich hier auch Bemerkungen der Kollegen von der 3D Fraktion.

Also, bitte alle nur “Adressen” taggen und wenn nichts mehr da ist, schaut euch das Bergland an und die Telekom-vernachlässigten Gebiete ohne DSL und…

Hallo Rolf,

Ich würde mich durchaus eher zur 3D-Fraktion zählen, aber ich muss sagen so ganz unrecht haben die Kollegen nicht.

Ich habe schon mehrere komplexe Gebäude in 3D gemappt und JOSM ist einfach nicht mit einem vernünftigen CAD-Programm vergleichbar. Es fehlen Winkel- und Maßfunktionen, zumal die Genauigkeit der OSM-Koordinaten oft nicht ausreicht. Außerdem basiert OSM nun einmal auf einem 2D-Datenmodell, weshalb die 3te (und 4te) Dimension nur über mehr oder weniger komplexe Taggingschemas dargestellt werden kann.

Für einfache Gebäude und Häuser funktioniert das ganz gut, aber bei komplexen Gebäuden stößt man da schnell an Grenzen (siehe Ursprungsthema).

Schau dir zum Beispiel mal das Straßburger Münster an. Das mag zwar in der F4 Map großartig aussehen, aber bearbeiten kann das der gewöhnliche Mapper nicht mehr und mit iD schon gar nicht. Da wimmelt es nur so von Relationen, überlappenden Wegen und doppelten Punkten.

Und ich kann mir vorstellen, dass sowas auch abschreckend (auf neue und renommierte Mapper) wirken kann.

Ich finde zum Beispiel das Konzept der F4 Map nicht schlecht: Komplexe Gebäude werden in einem extra Format modelliert und dann zusammen mit den 3D-OpenStreetMap-Daten auf der Karte gezeigt. Man könnte zum Beispiel eine eigene Datenbank mit 3D-Daten in einem geeigneten Format aufbauen. Das wurde glaube ich auch schon mal im Forum diskutiert. Damit könnte man eventuell sogar neue Mitwirkende gewinnen, das aktuelle Format ist nämlich für jemanden, der es gewohnt ist mit CAD-Programmen zu arbeiten, eher abschreckend.

Ich denke schon, dass es noch genug außerhalb von 3D und Indoor zu tun gibt, aber jeder darf bei OSM mappen, was ihm gefällt.

Indoor bei großen öffentlich zugänglichen Gebäuden halte ich schon für sinnvoll. Als Anwendungen sehe ich da Lokalisierung (z.B. per Wifi-Accesspoints) und Navigieren/Routing. Das wird mit mehreren Stockwerken übereinander schon kompliziert genug, ohne Filterung per Stockwerk ist man da aufgeschmissen.
Ein paar Ideen in S3DB wie die areas und den indoor-key halte ich auch für brauchbar bezüglich Indoor-Mapping.

Meine Befürchtung ist halt, dass wenn dann noch u.a. “das Gebäude bemalt wird”, das kein Mensch mehr (außer dem Ersteller vielleicht) in OSM bearbeiten kann.
Weniger ist manchmal mehr.

Ja, bemalen ist vielleicht grenzwertig, aber manchmal wäre es auch wünschenswert, wenn sich Anfänger von präzise erfassten Objekten abschrecken ließen. Was sollten sie auch verbessern? Simple 3D ist eigentlich simpel. Bisher hatte ich noch keine Probleme fremde Modelle zu verstehen.

Da hast du irgendwas falsch verstanden. Die Einwände hier kommen von Leuten, die 3D taggen (wollen), und in der Praxis merken, dass es einfach nicht funktioniert.

Und die Frage, auf die es hinausläuft ist doch, in was für einem Datenmodell es vernünftig funktionieren kann, weil zurzeit ist es echt ein Krampf.
Das ist keine Demontage von 3D, sondern eine Diskussion Pro 3D!

Nee,nee. Ich habe nur mal 'ne Nacht drüber schlafen müssen, um das zu verdauen. Im Prinzip habt ihr ja Recht. Wir brauchen halt eine Parallelmap in der Form von F4, aber natürlich auf OpenSource Basis! Denn alles, was man z.B. mit dem Blender machen könnte, ist auf der herkömmlichen OSM DB nicht unterzubekommen. Und da gibt es extrem viel Potential und Möglichkeiten. Fragt sich bloss, wie gehen wir mit der Grenze des heute machbaren um. Also die Möglichkeiten von S3DB / F3DB mit seinen noch experimentalen und tlw. nicht übereinanderstimmenden tags. Ich glaube, nur für einen der beiden Konzepte ist dann noch Platz auf der “alten” OSM.

Man kann es ja bei “simple” belassen und bei solchen extremen Einzelfällen (3D, aber auch indoor) auf eine externe Quelle (Website, Datenbank, Bild, Modell, …) verweisen. Es werden nie ganze Länder, Städte oder Gemeinden so extrem erfasst werden.

Wenn ich in der “Karte” auf ein “simple indoor” (Gebäude mit Durchgangsweg und POI’s) treffe, kann ich auch auf eine detailiertere (externe) verlinken (sofern vorhanden). Genauso bei einer Kirche - diese simple abbilden - und verlinken auf eine detailierter Darstellung.

Hier ist m.E. genau das passiert, das jemand “unsinnige” Daten löscht, weil er keine Ahnung von 3D hat.

EDIT: Link korr.

Der Link funkt. leider nicht.

.
Du meinst sowas wie (alt: Google 3D Gallerie) ? Jetzt nur eine andere Datenbank, die zur Nutzung für OpenSource freigegeben ist?
Und in der OSM 2D als tag mit einem Link genau auf das 3D (-Gebäude)? Wäre doch auch eine Überlegung wert. Bloss wer managed so eine Datenbank? Und gäbe es Ressourcen dafür?

Habe das Dach des östlichen Gebäudes in 3D per Revert wiederhergestellt.

Franz