Brücken – oder eine Apologie der Relationen

Nahmd,

Man fasst die die Brückenabschnitte der Straßen/Wege/Bahnlinien/Kanäle per Relation zusammen. Bei geschickt gewählten Rollen kann man auf Dauer auf sogar bridge=yes und layer=* an den Ways verzichten.

Mir ist klar, dass Relationen bei vielen OSM-Mitstreitern unbeliebt sind. Man sollte dazu aber wissen, dass bei unserer Profikonkurenz die Geometrieelemente keinerlei Semantik tragen und jegliche Semantik durch eine Art von Relation ausgedrückt wird. Das bringt erhebliche Vorteile gegenüber unserem Datenmodell, ist aber leider mit den vorhandenen Editoren nicht wirklich gut einzugeben.

Ein Beispiel für den Vorteil von Relationen: trägt man einen Bach als Linie ein, und dann die Eigenschaft “waterway=stream” in eine Relation, so ist das Eintragen des Namens auch nach einer Zerteilung des Baches in viele Segmente trivial, während bei der jetzigen Struktur man sehr leicht einen Schnipsel übersieht und es dem Namen-an-den-Bach-Schreiber unnötig schwer macht.

Tüte Popkorn aufmach und zurücklehn

Gruß Wolf

Die Brücke an sich ist ja ein Bauwerk und nicht zwingend ein Verkehrsweg. Warum sie nicht einzeichnen, wie wir es mit anderen Gebäuden auch machen? Über layers an den Wegen ist ja festgeegt, ob sie drüber oder drunter laufen.
Ausserdem ergibt das dann weitere Möglicheiten für erstellen von 3D-Modellen.

Danke braver Wolf :wink: ( http://forum.openstreetmap.org/viewtopic.php?pid=221760#p221760 )
1+ Bei diesem Thema bin ich ganz bei dir. Ich habe mir allerdings ein paar Berliner statt Popcorn geholt. ich wusste gar nicht das Wölfe auch in Wespennestern herum stochern :smiley:

Es wird wohl langsam Zeit, dass wir über ein neues Datenmodell nachdenken. :confused:
Aber wer traut sich da dran? Mir fehlt da das Fachwissen.

Ich schließe mich da mit an, das man nach dem bisherigen Modell eigentlich fast alles auf Relationen abbilden müßte. Das ganze wird dann noch durch das Schlüssel=Wert-Schema zusätzlich auf die Spitze getrieben, weil um dort die maximale Flexibilität zu haben, dütfte man nämlich nur noch mit =yes/no-Tags arbeiten. Ein typisches Beispiel ist vielleicht ein Restaurant/Cafe, das gleichzeitig noch ein Nachtclub ist und eine Lounge mit Bar im Keller hat (amenity=restaurant;cafe;bar;nightclub). Darf’s noch etwas länger sein? Macht bestimmt ganz viel Spaß bei der Auswertung, weil mit irgendwas müssen die ganzen Cores ja beschäftigt werden. :wink: Bei dem extrem häufigen Fall von Hotels mit Restaurant, hat man sich ja noch mit einem neuen (tourism=hotel) Key getrettet. Weil eine Schlüsse-Wert-Kombination bildet nunmal nur einen 1:1-Zusammenhang ab und nicht 1:n weshalb man dann z.B. highway=construction + construction=motorway macht und dabei völlig die Tatsache ignoriert, das für den Comüputer alles Tags gleichwertig sind und nichts miteinander zu zun haben, soll heißen, es gibt keinen Zusammenhang zwischen highway=construction und construction= bzw. analogem Tagging nach ähnlichem Muster.

Auf die Spitze wird sas Ganze dann noch dadurch getrieben, das man um eben solche 1:n-Beziehungen sauber abbilden zu können, man nach dem bisherigen Modell zu Relationen greifen muß, auch wenn es gar nicht darum geht, die Beziehung zwischen verschiedenen Geometrien herzustellen. Da würde aus meiner Sicht eine Baumartige Taggingstruktur echt helfen, denn das kommt der Realität meist viel näher, und man breucht keine schwer zu parsenden und zu verwaltenden Behelfslösungen wie highway:left:kerb:height=*, etc. mehr. Gerade wenn man sich z.B. http://wiki.openstreetmap.org/wiki/Building_attributes ansieht, ist doch etwas wie:


building+---roof------shape--------pitched
        |
        +---levels+---underground--2
                  |
                  +---top----------garden

viel sinnvollen, weshalb ich auch schon versucht habe, das für die API 0.7 vorzuschlagen, nur ist da evtl. der Text dazu unverständlich.

Wie man oben sieht, habe ich schon damit angefangen, u.a. auch wegen meiner Proposal-Strickerei.

Das sehe ich auch so.

Weide

PS: Und natürlich darf dann das Geometrieelement “Fläche” nicht mehr durch Relationen (Multipolygon) ausgedrückt werden, sondern muss ein Vollmitglied der Geometrieelemente werden. Das wird viele Relationsfeinde etwas versöhnlicher stimmen. :slight_smile:

Das derzeitige Datenmodell ist für viele User zu schwierig. Relationen (Routen, Multipolygone) überfordern leicht. Ich geb’s zu: Inseln in Flüssen oder Seen habe ich ursprünglich nicht als Multipolygone dargestellt. Erst durch einen Thread in der mkgmap development mailing list bin ich drauf aufmerksam geworden: da hatte ein Mapper eine Insel in einem Teich mal mit natural=coastline getaggt, und daraufhin war Wales überflutet… (nein, das war ein anderer Mapper, nicht ich). Aus dem Thread habe ich gelernt, wie es richtig geht, aber es liegen noch einige Überbleibsel von mir rum mit place_island, natural=land etc. statt Multipolygon.
Wer weiß, was da rauskomen würde, wenn Brücken auch so kompliziert werden, was probieren dann andere Mapper so alles aus, damit es “korrekt” auf der Karte dargestellt wird?
“Mapping for the renderer”? - Falsch! So lange es auf der Karte nicht “richtig” aussieht, habe ich wohl was falsch gemacht. Diese Einstellung ist nur allzu natürlich, und keineswegs etwa verwerflich.

“mapping for the renderer” sollte man meiner Meinung nur so verstehen:
“Verbiege und missbrauche kein key/value, damit etwas auf einer Karte sichtbar wird.”
Grundsätzlich sollte bei allen Überlegungen zu mapping-Schemen daran gedacht werden, ob Renderer die umsetzen könnten, wenn sie wollen.

Es gibt ja nun schon Brückenrelationen und so schlecht sind die nicht. Alles was fehlt, ist dass Mapnik sie auch darstellt. Dann werden die Leute sie auch eintragen. Ich glaube nicht, dass das ein Komplexitätsproblem ist, nur der Nutzen ist nicht ersichtlich, solange nicht wenigstens Mapnik damit klarkommt.

Welche ist denn deiner Meinung nach die bessere der nicht so schlechten? Ich würde gerne eine Variante bei meinen lane-Spielereien verwenden.
Natürlich sind mir auch Tipps anderer lieb. Kriterien sind:

  • Kann der Mapper das leicht verständlich umsetzen?
  • Können Renderer das überhaupt mit vertretbarem Aufwand darstellen (auch bei mehreren Brücken-layern übereinander)?

Ja, ich hatte nach dieser Diskussion auch mal nachgesehen und da hat mir http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels recht gut gefallen, wenngleich ich es auch noch nicht ausprobiert habe. Da wird auch Doppeltagging gemacht, aber man könnte, da es begrenzt definiert ist, ja den Anwendungen/Rendern beibringen, das sie alle Daten von den Wegen zu Gunsten denen der Relation wegwerfen sollen. Nur das löst nicht das Problem, wenn dann unerfahrene Mapper nur die Tags an den Wegen auf den neusten Stand bringen, woman man mal wieder beim Komplexitätsmanagment wäre.

Primär dachte ich an das hier: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels

Die Umsetzung durch den Mapper ist eher leichter als das aktuelle Layer & bridge=yes Zeug.
Über den Aufwand beim Rendern bin ich mir nicht völlig im Klaren, aber zumindest sollte es nicht so schwer sein, diese Relationen zu finden und die ‘across’ Wege über die ‘under’ Wege zu zeichnen. Outline sollte auch kein Problem sein, habe ich allerdings in freier Wildbahn noch nicht gesehen, so dass es sinnvoll wäre, wenn für Relationen ohne Outline ein anderer Weg gefunden würde. Aber auch da sollte es nicht zu komplexe Möglichkeiten geben, die zumindest bei Standardbrücken gut funktionieren. Beispielsweise man bestimme die kleinste zu einem beliebigen der ‘across’ Wege parallele Bounding-Box und male an die zwei Seiten, die nicht durch (oder nur durch die wenigsten) ‘across’ Wege durchbrochen werden, die Brückenmarkierungen. Wenn’s bei einigen Brücken nicht so toll aussieht, wird sich die Verwendung von Outline schon rumsprechen.

EDIT: Zu langsam. @Fabi: So viel Doppeltagging allerdings nicht. Im Prinzip eigentlich nichts außer dem bridge=yes und der Existenz der Relation. Aber wenn die Auswerter die Relation berücksichtigen, könnte bridge=yes schnell wegfallen. Und Probleme mit der Aktualität sollte es diesbezüglich kaum geben. Oh, und der Layer, aber ich frage mich, ob’s den überhaupt braucht, schließlich habe ich ja mehrere Relationen dann, daraus ergibt sich ja die Höhenverteilung direkt.

Ich dachte da eher an name=*.
Ja, und für accross, under und through sollten unbedingt auch weitere type=bridge/tunnel-Relationen erlaubt sein, weil es gibt ja selten mehrstöckige Brücken.

Vorsicht: name an der Relation steht für den Brückennamen, name an der Straße für den Straßennamen. Das ist unterschiedlich (und gehört nicht an die Brücke, wenn die keinen eigenen Namen hat).
Ich bin mir nicht sicher, ob für die across, under und through andere Relationen erlaubt sein müssen. Mir scheint, das ergibt sich auch so ausreichend. Bsp.:
Wege a, b, c:
Relationen:
{type=bridge, under=a, across=b}
{type=bridge, under=b, across=c}

scheint mir genügen um darzustellen, dass die Brücke mit c über der Brücke mit b über a liegt. Oder nicht? Deshalb denke ich auch, dass keine layer Tags notwendig sind. Ich lasse mich aber gerne überzeugen, dass das doch nicht reicht.

Ich dachte auch an die Namen von Brücken und größeren Tunneln, sonst ergibt das ja keinen Sinn.

Das reicht natürlich und ist eindeutig, war ein Denkfehler von mir.

Was mir etwas abgeht: Wie tagged man Brücken, welche auf 3 Ebenen spielen? z.B. http://www.panoramio.com/photo/21171875

Das nach meinem Verständnis Land (–> keine Layer-Angabe) darunter zwei Tunnel (Eisenbahn, Kanal/Fluss → layer=-1) und darüber eine Eisenbahnbrücke (–> layer=1).
Genau so ist es in OSM erfasst. (http://www.openstreetmap.org/?lat=48.18788&lon=16.338433&zoom=18&layers=M)

Edbert (EvanE)

Ich habe dabei den Relationsvorschlag von oben mit “over” und “under” gemeint. Obwohl ich da glaube, die falsche Brücke verlinkt habe.

Deshalb beschreibe ich mal den Fall den ich meine mit Worten (da ich die Stelle an die ich mich glaube zu erinnern nicht finde): Ähnlich wie im Bild oben, ist der Fluss deutlich unter der Erdoerfläche aber offen. Eine U-Bahn die im Untergrund verläuft kreuzt den Fluss oberhalb seines Pegels und auf der “Erdoberfläche” geht eine Straßenbrücke über den Fluss.
Bis jetzt hätte ich getagged: Fluss: Layer-2; U-Bahn Layer-1; Straße kein Layer mit dem oben angeführten over and under wird es irgendwie kompliziert (oder verstehe ich da etwas nicht?).

Ich glaube nicht, dass man in so einem Fall überhaupt so eine Relation verwenden müsste. Deren Sinn ist ja, Brücken zu beschreiben, bei denen mehr als ein Weg über die Brücke verläuft. Bei den Standardfällen sollten sie also nicht notwendig sein.

Übrigens: Angenommen man lässt das layer doch drin: Dann könnte man sich eigentlich die ‘under’ Wege sparen, oder? Ich meine, eigentlich geht’s ja nur darum, dass die oberen Wege nach den unteren geredert werden (wofür das layer zuständig ist) und halt eine Brückenoutline bekommen (die von den unteren Wegen soweit ich das sehe unabhängig ist). Würde die ganze Sache nochmal vereinfachen. Dann läuft es einfach nurnoch auf folgendes hinaus:
Hat man mehrere Wege, die aktuell mit bridge=yes, layer=x getaggt sind, aber physikalisch über eine Brücke laufen, dann entferne man diese Tags und erstelle eine Relation, die diese Wege sowie die Tags type=bridge, layer=x enthält und fertig.