Neues von maps.osm2world.org

Ok, ich probier mich grad aus. Ich hab hier http://www.openstreetmap.org/browse/way/189991255 zwei Haushälften, beide building = yes.
Würde ich also building:part = yes draus machen und ringsum (auf den Außenkanten) einen neuen Way mit building = yes machen, und gebe dem dann building:levels und roof:shape? Richtig?

Klingt vernünftig :slight_smile: Die Building:parts verändern überschreiben immer die Werte desjeningen Teils, die sie abdecken. Der Rest wird einfach vom Gebäudeumriss übernommen. Mit ein wenig Übung ist das gar nicht schwer, ich gebe aber zu an unserer Doku müssen wir noch feilen :confused:

Moin

geri-oc: es ist eigentlich ganz einfach, nur hier schwer verständlich geschrieben.
Zum einen: Ein Haus ist ein building. Nebengebäude sind wieder ein eigenes building. Man kann mehrere zusammenhängende Buildings mit einer Site relation zusammenfassen (z.B. Uni, Krankenhaus,…).
Sonderfall: Reihenhäuser, ob das nun x einzelne Buildings sind oder ein einziges, ist oft schwer zu erkennen. Im Zweifel ein einziges, großes.

In 2D reicht es, einfach den Grundriss des Hauses zu zeichnen und building=* dranhängen, hinzu entrance=* und die Adressdaten (an building=* oder an der entrance, ich nehme entrance, da kann man später genauer routen).
Für 3D nimmt man diesen Grundriss und trennt an den kanten, wo sich einzelne Tags unterscheiden, Bereiche ab. Jeder Bereich bekommt ein building:part=yes. Solange bis die gesame 2D Grundrissfläche mit einzelnen building:part bereichen ausgefüllt ist.

Sonderfall: 4 eckiges haus mit einem Fahrstuhlschacht in der Mitte. Da können sich building:part Bereiche überdecken.

Für die Tags gilt: an building=* kann man Tags kleben, die für alle Bereiche des Hauses gleich sind. Ansonsten kommen die Tags an die building:part=yes Polygonzüge.

Jetzt baut man eine Relation und packt den Grundriss, die building:part und die Eingänge des Gebäudes in die Realtion.
Fertig.

Soweit baut das aufeinander auf, angefangen vom 2D-Grundriss, der auch schon Tags für 3D haben kann (z.B. eine Garage oder ein einfaches Haus), ohne building:part oder ohne Relation.

Soweit verständlich?

Problematisch ist daran IMHO nur die Erkennung der Unterschiede (wo man das Gebäude in Teile aufteilt) und das man alle Tags zusammen hat. Dafür ist das 3D Building preset von kendzi in JOSM sehr hilfreich.
Ich gehe immer so vor: Umriss vom Haus zeichnen, building:part alle zeichnen, für jeden Building:part das 3d building preset öffnen, mit daten füllen, eingänge setzen, relation erstellen. Zufahrten/zugänge mappen. Barriers mappen auf Grundstück, weiter zum nächsten…

Amiga4000

Das klingt vernünftig und wäre eine mögliche Festlegung, aber es ist nicht der derzeit gültige Konsens.

Ich erinnere mich, dass wir auf dem 3D Workshop #2 darüber gesprochen haben (unter anderem weil OSM2World derzeit toleriert, wenn ein “Rest” vorhanden ist, der nicht von Gebäudeteilen verdeckt wird, und dann wie von dir beschrieben vorgeht). Ergebnis war aber, dass der Gebäudeumriss komplett ignoriert werden kann, sobald ein Gebäudeteil vorhanden ist und das haben wir auch so dokumentiert.

Von daher entspricht dieser Edit von Edbert auch nicht dem, wovon die anderen Entwickler ausgehen.

Gut, laut !i! ist mein Ansatz richtig, laut Amiga4000 brauche ich zusätzlich noch eine Relation, wo ich den building-way udn die beiden parts und die beiden Eingänge reinhaue. Was ist denn nun erwünschter. Und wie sieht die Relation aus:
type = building und die Rollen?

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden.
Wie z.b. in dieser Grafik:

Es ist das, was ich aus Simple 3D Buildings und der Diskussion zu OSM2WORLD hier entnommen habe.
Wenn andere 3D-Software andere/weitere Anforderungen haben, dann ergänze ich das gerne. Ich muss das halt nur wissen.

Mir war erst mal wichtig, diese Informationen überhaupt zu erfassen.

Neben der Seite Simple 3D Buildings habe ich diese Verwendung der Building-Relation auch auf der Seite Relations/Proposed/Buildings im Abschnitt “Other Usage" eingetragen. Dort habe ich auch noch roof:ridge und roof:edge aus User:Aschilli/ProposedRoofLines eingetragen. In letzterem steht lapidar der Satz “Roof lines are traced as ways and nodes and connected to the building via relations.”. Das habe ich auf diese Weise auch genauer festgelegt.

Wie immer bin ich für Hinweise auf Fehl-Interpretationen oder andere Verwendungen dankbar und werde das soweit sinnvoll einarbeiten.

Persönlich:
Natürlich bin ich über die Kaperung einer bestehenden Relation durch die 3D-Gemeinde nicht besonders glücklich. Allerdings sind die Verwendungen (bisher) disjunkt, so dass kein wirklicher Schaden entstanden ist.

Edit:
Danke für den Hinweis, Ich werde das gerne anpassen, sobald wir herausgefunden haben, was genauer zu sagen wäre.

Edbert (EvanE)

Das ist ja noch harmlos - bei uns gibt es sowas:

War drin gewesen - einfach phantastisch und dennoch bewohnbar. Architekt wohnt selber drin.
http://www.hs-rm.de/fab/ueber-uns/personen-im-fachbereich/personalseiten-fb-ab/prof-dipl-ing-architekt-johannes-fritz/architektur-architecture/wohnatelier-prof-johannes-fritz-bad-schwalbach/index.html
http://www.openstreetmap.org/browse/way/92810100

ufff… das zu taggen, könnte schon recht schwierig sein (ja wobei, mehrere building:part=yes; roof:shape=Richtiges_Tag_für_Abgerundetes_Dach).
Aber ein “normales” abgerundetes Dach, sollte zum taggen machbar sein - vorallem kommt sowas noch recht häufig vor (ich weiss gerade von Turnhallen, Einstell- und Vorführhallen, ein Schwimmbad). Gibt es da etwas? über taginfo bin ich auf roof:shape=round gestossen, was ich aber nicht so optimal finde - ausserdem wird es nur 11x eingesetzt.
(ob die Statik bei solchen Dächern optimal ist oder nicht, ist ein anderes Thema. Mir gehts nur drum, dass solche Dächer existieren und wenn ich nun schon anfange mit 3D-tagging, würde ich solche Dächer dann auch gleich demensprechend taggen)

Die Idee “Musikalischer Klang und architektonische Gestalt sollten sich in der Form ihres Hauses verbinden.” laut obigen Artikel erklärt die abgerundeten Formen dieses Hauses. Meiner Meinung nach ist das sogar sehr gut umgesetzt.

Edbert (EvanE)

Beispiel: Kirche:

Hab ich derzeit mit 2 Ways getaggt:
A : building=yes (Gesamtgebäude)
B : building:part=yes (Turm)

Wenn ich’s richtig verstehe fehlt also noch die Relation und A muss gleichzeitig auch ein building:part sein?

Haste 'ne Empfehlung? Bosch PLR 25 ok?

moin

chris66: wenn beides ein Gebäude ist, fehlt der building:part von A OHNE B (mal C genannt) und dann die Relation mit A,B und C.
So wie hier: http://84.115.129.21/gallery3/var/albums/OSM/ABC.png

Da sieht man, das B und C zusammen A ergeben. Getaggt werden B und C unterschiedlich, gemeinsame Tags (z.B. material=stone) kann an A dran.

edit

Nur bei dem hier (ABCD):
http://84.115.129.21/gallery3/index.php/OSM/ABCD

tagge ich das so, das C und D sich durchdringen (D ist z.B. ein Turm, der höher als C ist).
Z.B. tagge ich C mit height=10, und dann bei D height=20
Man kann bei D min_height= setzen, welches die height von C ist (sozusagen auf C einen Teil draufsetzen).
Z.B.: C height=10 ; bei D dann: min_height=10 height=20. So das beim rendern erst C gerendert wird und dadrauf dann D extra gerendert wird, das macht aber bei schrägen Dächern Probleme.
Eigentlich müsste man aus C den Teil von D ausschneiden, aber das ist zu kompliziert… edit

Amiga4000

Wenn ich das gewünschte Taggingschema richtig verstanden habe, sind da 2 Dinge die ich nicht verstehe, bzw. wo ich das Tagung nicht intuitiv und unnötig kompliziert finde:

  1. Warum muss jeder Teil mit building:part getagt werden. Angenommen jemand tagt eine Kirche und denkt sich, der Turm ist ja höher. Zeichnet das Kästchen rein als building:part, trägt die Höhe ein und denkt nicht an den Rest des Gebäudes. Ergebnis: In 3D wird nur der Turm gezeichnet. Der Rest des buildings nicht.
    Ein building ohne parts wird ja schliesslich auch in 3d gezeichnet. Das ist ja ein Widerspruch in sich. Dann dürfte man kein building ohne parts rendern.

  2. Warum soll ich das ganze in eine Relation packen, wenn die doch nichts abbildet, bzw. keinen Informationsgehalt hat? Das Building umrahmt schliesslich bereits das gesamte Gebäude, und die parts sich im building enthalten.

Dieser Satz aus dem Abschnitt Building parts sollte das erklären:
Note that if a building has at least one area tagged as building:part=yes,
the building outline is no longer considered for volume rendering,
unless it is also tagged as a building part.

Zu Deutsch:
Wenn es ein Building Part gibt, dann wird das Gesamtgebäude nicht mehr zum 3D-Rendern verwendet, es sei denn, es ist ebenfalls als Building Part erfasst.

Wie das genau zu interpretieren ist, und ob/wann die Relation notwendig ist, konnten wir in diesem Thread bisher nicht genau klären. OSM2WORLD braucht die Building Relation wohl nicht, wenn alle Teile als Building Part erfasst sind. Andere 3D-Renderer könnten ggfs. die Building Relation immer brauchen.

Die Building Relation stellt eine Verbindung zwischen den verschiedenen Building Part und dem Building Outline her. Von daher wäre es falsch zu sagen, dass sie keine Information enthält.

Edbert (EvanE)

Ich wollte es ja eigentlich nicht schreiben, aber wo nun gerade danach gefragt wird.
Bei Aldi-Süd gibt es ab diesen Donnerstag (also morgen 7.2.2013) einen Laser-Entfernungsmesser LRF-600 G für 100 Euro mit sechsfacher Vergößerung des Suchers und angegebenen (bis zu) 600 Meter Messdistanz.

Interessant vielleicht auch diese Vorstellung mit Leser-Kommentaren, um das Gerät wenigstens grob einschätzen zu können.
Eine Suche nach “LRF-600 G” sollte noch weitere Treffer bringen, da das Gerät bereits einmal bei Aldi Süd angeboten wurde.

Edbert (EvanE)

Ha, gerade gefunden:
http://wiki.openstreetmap.org/wiki/3D_building

:slight_smile: Amiga

Moin,
meine Fragen von gestern sind wohl in der Diskussion um building:part untergegangen, aber ich schiebe einfach nochmal eine hinterher:

Kann es sein, dass die Angabe des Standes der Daten nicht stimmt? “About” sagt “Last update contains data up to 2013-02-06 03:57:56.”, Gebäude von gestern sind aber nicht enthalten, obwohl der Timestamp der Tiles neu ist.

Bzgl. der building parts eine Frage, weil die Diskussion über die verschiedenen Möglichkeiten wohl nicht dokumentiert ist: Warum wird das eigentliche Building ignoriert, sobald ein building:part vorhanden ist? Für mich klingt das am Ende sehr kompliziert (gerade auch wenn noch eine Relation gefordert wird). Da muss ich things-change zustimmen, das klingt für mich nach einem komplizierten Tagging um das Rendering einfacher zu gestalten.

Glaube ich eigentlich nicht, liegt aber evtl. daran, dass das ganze etwas komplizierter ist: Das Datum in der About-Seite sagt, wann wir den letzten Dump runtergeladen haben. Zu diesem Zeitpunkt sind die darin enthaltenen Daten aber schon ca. 1 Tag alt. Alle Tiles die nach diesem Zeitpunkt gerendert werden, sind von diesem neuen Dump. Den Zeitpunkt der Kachel solltest du dann bei zoom=13-18 anschaun. Bei zoom=12 ist es immer das Datum der aktuellsten zoom=13-Kachel.

Falls du dennoch meinst, dass hier ein Fehler vorliegt, sag mir bitte die Tilenummer, dann überprüfe ich das.

Das ist technisch etwas schwer weil der Mapnik-Layer ja nicht von uns kommt. Wenn wir den jetzt drehen stehen aber alle Beschriftungen,… auf dem Kopf. Außerdem müssten wir das Drehen selbst auch noch irgendwo programmieren: Entweder unsere Server als Proxy verwenden und dort on-the-fly drehen oder irgendwie in OpenLayers mit JS drehen. Aber wegen den Beschriftungen denk ich nicht dass wir das machen werden oder es überhaupt viel Sinn macht.

Ich versuche mal etwas Klarheit in die Diskussion um building:part zu bringen. Dabei ist es wichtig zu unterscheiden, 1. was “Simple 3D Buildings” spezifiziert, 2. was evtl. eine sinnvolle Konvention wäre und 3. was OSM2World unterstützt.

Die Vorgehensweise nach Simple 3D Buildings:

  • building=yes wird für die Gesamtfläche genutzt. Dort stehen auch die Tags fürs Gesamtgebäude.

  • die Teile werden jeweils als building:part eingetragen. Dabei muss die Gesamtfläche noch einmal komplett mit building:part-Flächen überdeckt sein, einen “Rest” darf es nicht geben.

  • Tags, die nur für ein Gebäudeteil gelten, stehen am Gebäudeteil - ansonsten werden Tags wie Höhe oder Material vom Gesamtgebäude “geerbt”.

  • eine Relation mit type=building wird angelegt, die die building-Fläche und die building:part-Flächen als Member enthält. Die Rolle für Gebäudeteile ist dabei nicht spezifiziert und auch eigentlich egal, da ein Teil ja bereits durch das building:part-Tag als solches erkennbar ist.

Es scheint in der Diskussion zwei Aspekte dieses Schemas zu geben, die besonders oft als unpraktisch empfunden werden: Die Relationen sowie die Notwendigkeit, die gesamte Fläche noch einmal mit building:part abzudecken.

Die Relationen wurden aus zwei Gründen eingeführt: Weil sie in einigen wenigen Fällen unverzichtbar für eine einfache Auswertung sind (nämlich dann, wenn sich die “Footprints” von Gebäuden in 2D überlappen), und weil sie auch in anderen Fällen die Auswertung effizienter und einfacher machen.
Sehr viele Mapper verwenden die Relation allerdings in der Praxis bei Fällen der zweiten Gruppe nicht. Wer die Relation unpraktisch findet, der sollte sie meiner Meinung nach lieber weglassen als gar keine 3D-Gebäude zu taggen. OSM2World benötigt die Relation nicht.

Dass wir uns auf dem 3D-Workshop entschieden haben, eine komplette Überlappung der Gesamtfläche mit building:part-Flächen zu fordern, hat auch wieder mehrere Gründe. Der wichtigste ist aber, dass wir nichts am Tagging normaler Gebäude, also der building-Flächen, ändern wollten. Die Tags am building=* (also name etc., aber auch Dinge wie height) sollen daher weiterhin fürs Gesamtgebäude gelten.
Das bedeutet, dass z.B. ein Kirchturm mit ins height-Tag am Gesamtgebäude eingerechnet werden müsste, auch wenn der Kirchturm noch einmal einzeln als building:part gemappt ist. Also würde das Gesamtgebäude zwangsläufig alle niedrigeren Teile “verschlucken”, wenn es trotz Vorhandensein eines oder mehrerer building:part weiterhin gerendert würde.
OSM2World ist auch hier wieder etwas toleranter: Flächen von Gebäudeteilen werden von der Gesamtfläche subtrahiert und der verbliebene Rest wird mit den Attributen - Höhe, Material etc. - des Gesamtgebäudes gerendert. Das funktioniert allerdings nicht zuverlässig, wird von anderen Renderern definitiv nicht unterstützt und führt bisweilen zu Darstellungsfehlern. Hier bin ich mir daher nicht sicher, ob das wirklich eine gute Idee ist.

Ich hoffe, dass diese Erklärung etwas weiterhilft. :slight_smile:

PS: Zum Datum hat Peda ja schon etwas geschrieben. Ich werde später auch noch mal alle Posts durchgehen, um nach “untergegangenen” Fragen zu suchen.