3D-Mapping: Beispielgebäude?

things-change · 2013-10-24T06:20:02.000Z

3dr:type tags wird dir nur kendzi darstellen. roof:shape=x ist der tag für Dachformen. Wenn ich es in der Tabelle richtig gesehen habe, ist 2.5 pyramidal. Ich bin mir aber nicht sicher, ob f4map das darstellt.

btw. wer hat denn die in #8 angesprochenen Fabrikdächer sawtooth genannt? Die Dachform nennt sich m.E. shed

tunnelbauer · 2013-10-24T06:48:58.000Z

Hier steht was F4 darstellt… (auch in Bezug auf Dächer)

_i · 2013-10-24T10:58:25.000Z

Da es derzeit offensichtlich Verwirrungen gibt, wäre es aus eurer Sicht sinnvoller im Wiki herauszustellen, dass S3DB der derzeitige Mapping-Standard ist, der auch breiter unterstützt wird?
Dann müsste ich wissen, wie ihr zu euren Informationen gelangt seid, damit ich das dort nochmal unterstreichen kann.

things-change · 2013-10-24T13:31:41.000Z

Kendzi hat halt viele Sachen schon dargestellt, die über S3DB hinausgehen. Dafür wurden bewusst die kryptischen 3dr:… tags benutzt, um den nicht Standard Status zu unterstreichen. Allerdings wurden für manche tags wie 3dr:type=1,2…9 Namen für das S3DB Tag roof:shape gefunden. Also geht das über den Grundstandard S3DB eigentlich hinaus, aber das ist ja noch nicht mal ein neues Tag, sondern nur neue Values, und es wird dargestellt, so dass es praktisch schon wieder Standard ist…

Falls du auch meinen Post meintest, diese Fabrikdächer heissen Sheddächer und nicht Sawtoothdach. Das ist kein Tagging-Konsens; vielleicht wurde ‘shed’ auch noch nie verwendet, weil im Wiki ‘sawtooth’ steht. Aber es ist in meinen Augen schlicht und ergreifend falsch.

jeffdameth · 2013-10-24T14:02:03.000Z

@things-change: Eine google Bilder suche für shed vs sawtooh roof deutet auf gängige Interpretation beider Dachtypen hin. Wobei shed eher skillion entsprechen würde.

streckenkundler · 2013-10-24T14:14:47.000Z

j3d:

@things-change: Eine google Bilder suche für shed vs sawtooh roof deutet auf gängige Interpretation beider Dachtypen hin. Wobei shed eher skillion entsprechen würde.

Shed ist der bautechnisch korrekte Begriff für diesen Dachgrundtyp.
Baulexikon
Dissertation Kerstin Renz (zur Geschichte)

Sven (gelernter Zimmermann)

tunnelbauer · 2013-10-24T14:22:26.000Z

Sheddach ist aber eigentlich der eingedeutsche (bzw im deutschsprachigen Raum gebräuchliche) Begriff.

Gehst du aber auf wiki > http://de.wikipedia.org/wiki/Sheddach > Drückst du > Languages > English kommst du unter Saw-tooth roof wieder raus…
Somit dürfte der englische Muttersprachler “Saw-tooth -roof” sehr wohl kennen und in der 3D-Sache auf OSM wurde anscheinend dem entsprochen…

Aber ich glaube es geht jetzt hier nicht um die richtige Übersetzung bei der Sprache, sondern dass der Server, der diese Daten darstellt darunter das Richtige versteht…

Tordanik · 2013-10-25T20:16:05.000Z

Ich sehe noch Klärungsbedarf bei der Übersetzung von OSM-4D zu einem roof:shape-Wert. Zunächst einmal dies hier: Der OSM-4D-Rooftable listet

als “sawtooth”. Hier sind die steileren Flächen allerdings senkrecht. Wäre dieser Winkel etwas, was man über einen Parameter einstellen können sollte? Oder ist das eine komplett eigene Dachform?

things-change · 2013-10-25T21:01:02.000Z

Wenn ich mir die Google Bildersuche anschaue, ist sawtooth wohl beides. Sie erfüllen ja auch denselben Zweck. Die steilere Front enthält die Fenster und zeigt gen Norden (auch etwas, was der Renderer gleich berücksichtigen sollte?), und ermöglichen so eine blendfreie Tageslichtbeleuchtung.

Allerdings gibt es auch ‘Designdächer’, wo der Sägezahn keinen Zweck erfüllt und dann wohl auch keine Fenster hat.

Winkel einstellen wäre super, allerdings sollte man dann aber wohl auch die Anzahl der Zähne tagen können.

Netzwolf · 2013-10-25T22:43:15.000Z

Nahmd,

things-change:

Wenn ich mir die Google Bildersuche anschaue, ist sawtooth wohl beides. Sie erfüllen ja auch denselben Zweck. Die steilere Front enthält die Fenster und zeigt gen Norden (auch etwas, was der Renderer gleich berücksichtigen sollte?), und ermöglichen so eine blendfreie Tageslichtbeleuchtung.

Allerdings gibt es auch ‘Designdächer’, wo der Sägezahn keinen Zweck erfüllt und dann wohl auch keine Fenster hat.

Winkel einstellen wäre super, allerdings sollte man dann aber wohl auch die Anzahl der Zähne tagen können.

Und die Anzahl und Größe der Fenster in jedem Winkel.

Gruß Wolf

Tordanik · 2013-11-02T16:07:59.000Z

things-change:

Winkel einstellen wäre super, allerdings sollte man dann aber wohl auch die Anzahl der Zähne tagen können.

Anzahl Zähne hatte ich für selbstverständlich gehalten. Auch wenn ich zugegeben noch keinen Schlüsselnamen habe - roof:ridge_count? roof:shape_repetitions, um auch eine Reihe runder Dächer abzudecken?

Auf jeden Fall habe ich mir die Idee mal notiert: https://github.com/tordanik/OSM2World/issues/83
Vorher sollte es natürlich noch mit der internationalen Community diskutiert werden.

@Netzwolf: Eins nach dem anderen.

things-change · 2013-11-03T06:52:09.000Z

Was noch zu bedenken wäre: Die ‘Zähne’ decken eigentlich nie das komplette Dach ab, sondern es bleibt ein Rand zum Begehen des Daches. Sollte man das über Tags beschreiben, oder sollte man den Sägezahnbereich als Fläche einzeichnen, und als building:part bzw. roof:part beschreiben?

marek_kleciak · 2013-11-03T09:00:58.000Z

#21:

Wäre dieser Winkel etwas, was man über einen Parameter einstellen können sollte? Oder ist das eine komplett eigene Dachform?

Ich habe mich beim “Erfinden” dieser Form an der Häufigkeit dieser Form gerichtet. Sie bildet etwa 60% solcher Dächer ab.
Ich bin mir im Unklaren, wie man hier richtig vorgeht. Es gibt zwei “Sondersituationen” die am öftesten vorkommen:
A- eine Seite ist senkrecht (wie bei dem zitierten Beispiel )
B- Beide Seiten haben gleiche Neigung (oft bei Gewächshäuser)
Du fragst nach:
C - unterschiedliche Winkel beidseitig
Vielleicht sollte man für die 3 Fälle spezielle Tags bzw. Subtagging haben?
Eine Idee wäre dass man (dem Sinn nach) etwa schreibt:

Keine Verschiebung von dem First
First mittig
First um X Meter verschoben?

Die Arbeit mit Winkel ist aus dem was ich kenne für viele Leute schwieriger als die Arbeit mit den Abständen.

#25: Ich würde dies als building:part beschreiben: Oft sind diese Randflächen nicht identisch bzw. die Geometrie des Daches ist nicht mit dem Gebäudegrundriss identisch. Z.B. Gebäudegrundriss trapezförmig, Sägedach rechteckig.

Viele Grüße,
Marek

marek_kleciak · 2013-11-04T12:07:12.000Z

Recht gut gemacht!
:
http://map.f4-group.com/#lat=42.3605232&lon=-71.0508820&zoom=19&ui.showMenuPage=true&menuPage.type=search&menuPage.id=Boston&camera.theta=65.103&camera.phi=64.458

ulmtuelp · 2014-03-09T16:54:13.000Z

Hallo Gemeinde,

ich habe mich ein wenig im 3D-Mappen versucht. Zuerst einfache Fälle. Dann folgende:

ein Haus mit unterschiedlichen Farben je Stockwerk (bzw. horizontal unterschiedliche Farben)
(Reihen-)Haus mit unterschiedlichen Gebäudefarben der Einheiten. Geht zwar mit building:part, aber dann zerfällt das Dach in seltsame Formen bei F4 und osm2world.

Gibts da schon Lösungsvorschläge?

Beste Grüße!

things-change · 2014-03-10T09:37:49.000Z

ulmtuelp:

ein Haus mit unterschiedlichen Farben je Stockwerk (bzw. horizontal unterschiedliche Farben)

Da musst du für jedes Stockwerk ein building:part nehmen und mit der entsprechenden min_height und height versehen. Evt. noch die Anzahl der Stockwerke der entsprechenden parts mit building:levels/building:min_level. Siehe auch hier (Absatz Höhe):
http://wiki.openstreetmap.org/wiki/DE:Simple_3D_Buildings

ulmtuelp:

(Reihen-)Haus mit unterschiedlichen Gebäudefarben der Einheiten. Geht zwar mit building:part, aber dann zerfällt das Dach in seltsame Formen bei F4 und osm2world.

Wenn die parts quadratisch bzw. rechteckig sind (wie ja meistens bei Reihenhäusern?), sollte die Darstellung richtig sein. Nur bei anderen Grundrissen kommen u.U. merkwürdige Formen raus. Man könnte dann jede Dachfläche als skillion taggen, um die einzelnen Flächen explizit festzulegen, aber das ist natürlich ein größerer Aufwand.

Ein link wäre hilfreich.

MKnight · 2014-03-10T13:05:29.000Z

ulmtuelp:

(Reihen-)Haus mit unterschiedlichen Gebäudefarben der Einheiten. Geht zwar mit building:part, aber dann zerfällt das Dach in seltsame Formen bei F4 und osm2world.

Ist mir schon paar mal passiert; wenn die Gebäude-parts pseudo-quadratisch sind geht das Dach manchmal in die falsche Richtung (längste Seite=Richtung). Abhilfe schafft da roof:orientation zu setzen.

ulmtuelp · 2014-03-12T07:12:41.000Z

Danke für die zwei Antworten.

Ein link wäre hilfreich.

Ja da sind sie:

Mapnik
F4 Map

oder auch dieses:

Mapnik
F4 Map

Ich denke im Bing-Lufbild kann man gut erkennen wie es aussehen sollte.

edit: Link korrigiert

things-change · 2014-03-12T07:54:22.000Z

Ich würde erstmal alle parts in eine building-relation packen. (So soll es ja eigentlich auch gemacht werden). Oft geht es auch auch ohne, aber manchmal führt es zu merkwürdigen Darstellungen. Der 2. F4Map-link ist falsch. Zum ersten:

Da du eh Adress-Nodes gesetzt hast, würde ich die Doppelhaushälfte gar nicht in parts teilen. Ein part für die Grundfläche ohne den Anbau. Dann hast du eine rechteckige Fläche. roof:shape gehört auch an den part selbst. Dann sollte das passen.
Den Anbau selbst könntest du mit roof:shape=flat und entsprechenden Höhenangaben taggen, oder wenn es realitätsgetreuer werden soll, den part als quadratische Fläche in das Gebäude rein überlagern und dann mit roof:shape=pyramidal versehen.

Irgendwo hast du auch noch einen ‘colour’ Tippfehler.

ulmtuelp · 2014-03-12T10:19:53.000Z

Da du eh Adress-Nodes gesetzt hast, würde ich die Doppelhaushälfte gar nicht in parts teilen. Ein part für die Grundfläche ohne den Anbau. Dann hast du eine rechteckige Fläche. roof:shape gehört auch an den part selbst. Dann sollte das passen.
Den Anbau selbst könntest du mit roof:shape=flat und entsprechenden Höhenangaben taggen, oder wenn es realitätsgetreuer werden soll, den part als quadratische Fläche in das Gebäude rein überlagern und dann mit roof:shape=pyramidal versehen.

Irgendwo hast du auch noch einen ‘colour’ Tippfehler.

Die Doppelhaushälfte hatte ich in building:part geteilt da (Ausgangspunkt meiner Frage) beide unterschiedliche Farben haben. (Adressen an building:part werden in Mapnik nicht gerendert. daher einzelne Adress-Nodes gesetzt. Ich weiß , für den Renderer getaggt)
Die Verlagerung des Anbaues ins Hauptgebäude würde wahrscheinlich beim 3D-Rendern ein gutes Ergebnis bringen, entspräche aber irgendwie nicht der Realität. Es fehlt sowas wie ein side_hipped tag (bzw. das dieser gerendert wird.)
Relation type=building hole ich noch nach, habe ich erst später im Wiki gelesen. Beim zweiten Beispiel (Link oben korrigiert, ist vielleicht weniger kompliziertes Beispiel aber sieht auch nicht so gut aus.) hatte ich das schon so gemacht.

Ich finde die 3D-Sache ja sehr interessant, scheint mir aber dass die Sache noch am Anfang steht.