Umgang mit Brücken man_made=bridge und Objekten dieser Ebene

EinKonstanzer · 2017-09-25T16:07:08.000Z

**Fortsetzung der Diskussion der folgenden Note: https://www.openstreetmap.org/note/339113#map=19/51.22645/6.79909&layers=N**Beschreibung

In dem Bereich wurden die Tunnel-Tags der Schienen entfernt. Den Straßen fehlt jedoch layer und bridge Kennzeichnung.
Situation ist Murks.

Der Bereich ist eigentlich viel zu großflächig um da mit Brücken und Brückenbreite zu handtieren.Dem Bereich die layer 0 zu geben ist absolut gerechtfertigt.
Ob man den Schienen den Tunnel-Tag anhängt kann man Streiten. Schienen am besten -1 setzen und fertig.
Und nicht layer mit level verwechseln.
Erstellt von EinKonstanzer vor mehr als 2 Jahre

Dieser Hinweis enthält Kommentare von anonymen Benutzern, die unabhängig geprüft werden sollten.

Kommentar von Athemis vor mehr als 2 Jahre

Gebe Dir völlig Recht, was die Situation angeht :). Hab' mich mal dran versucht, auch unter Benutzung eines Proposals für Brückenrelationen ([https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels](https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels)). Layers=0 an den Straßen ist eigentlich unnötig, da alles implizit layer=0 ist, hab's aber mal so gelassen. Schienen sind bereits layer=-1. Ansonsten habe ich die Straßenführung den aktuellen Gegebenheiten angepasst und den ÖPNV nach PTP umgestellt.
Kommentar von Athemis vor mehr als 2 Jahre

Was mir da aber eigentlich gar nicht gefällt, sind diese Flächen mit "highway=pedestrian". Imho müsste man die eigentlich mit den Benachbarten Straßen verschmelzen.
Kommentar von hsimpson vor 10 Monate

Also optimal ist das ganze ja jetzt immer noch nicht. Straßen ohne bridge=yes führen über ein man_made=bridge, worunter eine Bahn mit Tunnel=yes führt. Dazu total verkorkste pedestrian-Flächen mit Füßwegen, die im nichts enden.
Ich sehe hier zwei Lösungen:
1. (mein Favorit): bridge=yes an alles klatschen, was oben läuft und die Tunnel-Tags weg. Straßenebene bekommt layer=1 und die Schienenebene ein implizites layer=0. Trifft meiner Einschätzung nach eher die Situation.
2.: Die man_made=bridge - area kommt weg. Die layer-Werte bleiben, wie sie jetzt sind. Den Bruch Straßengelände-Bahngelände muss man dann durch barrier=fence und verschiedene landuse markieren.
Dazu sollte man in beiden Fällen das Bahngelände mit landuse=railway als solches markieren. In Fall 2 wird es im Bereich des Tunnels unterbrochen.
Die Fußwege sollten seperat angegangen werden.
Kommentar von Lukas458 vor 5 Tage

Hallo Leute,
also ich bin mir auch sicher, dass es sich hierbei um eine Brücke handelt. Daher wäre Nummer 1 auch mein Favorit. Ich würde mich dem in den nächsten Tagen annehmen, wenn niemand etwas dagegen hat oder noch andere Einwände hat(?)
Kommentar von Lukas458 vor 5 Tage

Bei den Straßenbahnschienen könnte es dann natürlich zumindest theoretisch in der Kartendarstellung zu einem Bruch kommen wegen dem Layer - sichtbar wird das bereits jetzt bei der etwas weiter nördlich gelegenen Franklinbrücke in Düsseldorf. Aber das ist Sache des Renderers, nicht Sache der Daten.
Kommentar von Lukas458 vor 3 Tage

So, ich habe jetzt mal alles entsprechend geändert. Es müsste jetzt besser aussehen. Ich finde schon, dass es sich eindeutig um eine Brücke handelt. Bitte nachschauen und ggf. nachfragen, wenn etwas nicht passen sollte.
Kommentar von hsimpson vor etwa 21 Stunden

Hi, für mich sieht das schon viel besseer aus so. Nur die Fuß- und Radwegführung schreit noch förmlich nach einer Überarbeitung ;)
Grüße
Kommentar von hsimpson vor etwa 21 Stunden

Nachtrag: Aus meiner Sicht ist die bride-Realtion auch überflüssig, da sie keinerlei Mehrwert bringt. Wenn man die löscht kann man auch unter der Brücke noch Ways zusammenlegen.
Grüße
Kommentar von Lukas458 vor etwa 3 Stunden

Hi,
danke für deine Kommentare! Mit dem ersten Punkt meinst du, dass man wenn schon, dann alle vorhandenen Fuß- und Radwege ergänzen sollte? Das wäre natürlich möglich, außer ich habe dich hier falsch verstanden. Zum zweiten - also von mir aus kann diese Brücken-Relation auch weg. Ich gebe dir da völlig Recht. Nur die bridge-Area würde ich natürlich belassen, aber das sind ja auch zwei verschiedene Dinge. Für die Eisenbahnschienen darunter wäre es bei ohnehin (jetzt implizitem) layer=0 sicherlich einfacher ohne diese ganzen Aufteilungen der Ways. Ich werde mich innerhalb der nächsten Woche an eine Umsetzung machen.
Kommentar von hsimpson vor etwa 2 Stunden

hi, die man_made=bridge-area ist natürlich korrekt! Ich meinte diese Relation hier: [https://www.openstreetmap.org/relation/4867387](https://www.openstreetmap.org/relation/4867387)
-
Zu den Fußwegen:
Normale Bürgersteige sollten mittels des "Sidewalk"-Tags erfasst werden, nicht als eigener Way: [https://wiki.openstreetmap.org/wiki/DE:Key:sidewalk](https://wiki.openstreetmap.org/wiki/DE:Key:sidewalk)
-
Viel ist eben nicht immer richtig und gut! Manchmal macht es das ganze nur unübersichtlich und führt vor allem auch zu falschen Routig-Ergebnissen!
-
Auch mit den Pedestrian-Areas habe ich so meine Probleme. Klar, die kann man eintragen, aber dann bitte bis zum Way der Straße, da diese auch in der Realität direkt an die Straße grenzen. Oder aber man lässt die einfach weg und hat auch nichts wirklich verloren, da sie auch keinen nennenswerten Mehrwert bringen, dafür aber Fragen aufkommen lassen, wie "Wenn die jetzt als Pedestrian erfasst werden, warum dann nicht auch der angrenzende Fußweg?"...
-
Auch der Name "Vinzensplatz" ist für mich verdächtig, da keine Straße außenrum diesen Namen trägt, nur die eine kleine Verkehrsinsel! Das sollte mal vor Ort überprüft werden.
-
Viele Grüße
Kommentar von Anonym vor etwa 2 Stunden

Zum Thema "Vinzenzplatz" kann ich bestätigen, dass das tatsächlich so korrekt ist. Vor Ort hat die kleine Insel ein eigenes Straßenschild.
Kommentar von Athemis vor etwa 2 Stunden

^^manchmal sollte man sich auch wieder anmelden :-P Das Posting war von mir ;-)
Kommentar von EinKonstanzer vor 8 Minuten

Ist ein Weg eine Brücke dann machen wir bridge=yes. Bei 100 Wegen sind das 100 Brücken...
Das ist aber an der Stelle konzeptionell völliger Mist.
Das hier ist eigentlich keine Brücke mehr sondern eine Ebene für sich. Die einzelnen Objekte liegen in der Brückenebene. Damit das klappt ist die Brücke mit all den Objekten in der Brückenebene in eine Relation zusammen zu fassen. Diese gibt es ja schon… :)
Genau genommen müsste jetzt nur noch an die man_made=bridge layer & level gepappt werden und fertig ist die Kiste. Es schadet sicher nicht die Infos zusätzlich an die Objekte auf der Brücke hinzu zu fügen.
Die Gleise drunter sind davon völlig unberührt. So als ob es gar keine Brücke geben würde.
Kommentar von EinKonstanzer vor 4 Minuten

Zusammengefaßt: Mir gefällt die aktuelle Lösung so in der Form gar nicht. Im Wiki habe ich auf die Schnelle nichts konkretes dazu gefinden.

hsimpson · 2017-09-25T16:13:21.000Z

Hi,

es sollte nicht allzu schwer sein, alle Elemente innerhalb einer man_made=bridge - area mit bridge=yes und demselben Layer als zugehörig zu der Brücke zu erkennen. Derzeit ist die Situation so, dass die Gleise unter der Brücke für die Brückenrelation aufgeteilt wurden, das halte ich für totalen Unsinn. Man kan alleine durch die geometrische Lage und korrekte layer-Angaben ohne Probleme erkennen, ob sich ein Element unterhalb einer Brücke befindet, auch dazu braucht es keine Relation. Es ist nicht ohne Grund der Fall, dass die Brückenrelation unter den wenigen relationstypen zu finden ist, die bisher noch immer keine Bestätigung durch ein Voting bekommen haben. https://wiki.openstreetmap.org/wiki/DE:Types_of_relation

Zusammengefasst: Nein, es ist durchaus erkennbar (auch für ein Programm), dass es sich hier nicht um 100, sondern um eine einzige Brücke handelt. Dafür braucht es keine (Sammel-)Relation.

Daneben ist das hier der Bauform nach definitiv eine Brücke. Ich kenne sie sehr gut und bin schon des öfteren drüber und drunter gefahren, der einzige Unterschied ist nur, dass sie etwas breiter ist und über einen Einschnitt führt.

Layer an der Brücke fehlt natürlich noch, das hatte ich übersehen. Level halte ich für falsch, das gehört zum Indoor-Mapping, und indoor ist das hier definitiv nicht.

Grüße

Edit: Layer-Angabe an der man_made=bridge ergänzt

hsimpson · 2017-09-25T16:20:56.000Z

Allerdings muss ich sagen, dass ich die Form der man_made=bridge-Area sehr komisch finde. Meiner Ansicht nach müsste die im Bereich der Brückenüergänge eher gradlinig laufen.
Grüße

Elefant_aus_Wuppertal · 2017-09-25T19:18:30.000Z

Allerdings muss ich sagen, dass ich die Form der man_made=bridge-Area sehr komisch finde. Meiner Ansicht nach müsste die im Bereich der Brückenübergänge eher gradlinig laufen.

Da stimme ich zu! Aber kennt den jemand die genauen Umrisse der Brücke und könnte das korrigieren/verbessern?

Ansonsten finde auch ich, dass die Bauform eines Objekts (also eine Brücke, wenn auch mit großer Fläche) berücksichtigt werden sollte.

Bezüglich footway/sidewalk muss man sich halt einigen:
-entweder man trägt alle footways/sidewalks einzeln als Ways ein

oder man trägt alles mit sidewalk=* ein, verzichtet dann aber auch auf jegliche Kreuzungs-Wege (footway=crossing) etc.

Im Zweiten Fall wäre ich dafür, die pedestrian-Areas dann wegzulassen. Die zu kartieren ist immer so eine Sache, weil, wenn man die direkt an die Straßen-Ways grenzen lässt, dann sind sie zwar einerseits so verbunden, wie in der Realität, aber andererseits sind die pedestrian-Areas dann zwingend größer als auf Luftbildern, da die Straße ja “nur” als Way gezeichnet ist und somit schmaler ist, um eine Verbindung herzustellen muss man die Fußgänger-Fläche dann breiter zeichnen.

hsimpson · 2017-09-25T19:40:20.000Z

Lukas458:

-entweder man trägt alle footways/sidewalks einzeln als Ways ein

Das wäre sachlich schlicht falsch, da eigene Ways nur bei baulicher Trennung infrage kommen. Ist ein Bürgersteig also bspw. durch einen Grünstreifen oder eine Hecke von der Straße abgesetzt, ist ein eigener Way korrekt, aber ein normaler Bordstein reicht dazu nicht aus.

Lukas458:

verzichtet dann aber auch auf jegliche Kreuzungs-Wege (footway=crossing) etc.

Fußgängerüberwege werden durch eine highway=crossing Node beschrieben. Siehe: https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcrossing

highway=crossing sollte IMO nur dann verwendet werden, wenn z.B. eine Fußgängerampel auf einer Straße mit baulich getrennten Richtungsfahrbahnen ist, bei der die Gehwege nicht baulich getrennt sind. Aber auch in dem Fall sehe ich eigentlich keinen Mehrwert davon, dass an dem Way jetzt zusätzlich ein footway=crossing steht. Die Node mit highway=crossing sollte vollkommen ausreichen um einen Fußgänger- oder Radübergang zu kennzeichnen.

Abgesehen davon, bekommt man ziemliche Schwierigkeiten, wenn der Überweg für Radfahrer nutzbar ist. Das müsste man dann korrekt als highway=path mit foot=designated und bicycle=designated eintragen, aber ist das dann ein footway=crossing, cycleway=crossing, oder doch ein path=crossing? Es gibt schon Gründe, warum das nicht so weit verbreitet ist.

Viele Grüße

geri-oc · 2017-09-26T07:02:57.000Z

hsimpson:

Das wäre sachlich schlicht falsch, da eigene Ways nur bei baulicher Trennung infrage kommen. Ist ein Bürgersteig also bspw. durch einen Grünstreifen oder eine Hecke von der Straße abgesetzt, ist ein eigener Way korrekt, aber ein normaler Bordstein reicht dazu nicht aus.

Man sollte einmal das englische WIKI nutzen, ich weiß nicht, warum deutsche WIKI abweichend sind.

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
Dort sind auch Beispiel verlinkt.

Das Propsal ist von 2011:
http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way

OSM ist nicht nur “autofreundlich”, sondern sollte auch für Fußgänger und andere nützlich sein.

hsimpson · 2017-09-26T09:51:05.000Z

geri-oc:

OSM ist nicht nur “autofreundlich”, sondern sollte auch für Fußgänger und andere nützlich sein.

Wenn du damit sagen willst, die Erfassung von Gehwegen als sidewalk=left/right/both sei Fußgängerunfreundlicher, dann ist das totaler Unsinn.

Die Erfassung von Gehsteigen als eigenen Way ist viel mehr das, was routingunfreundlich ist, und damit für Fußgänger total suboptimal. Zum einen führt das zu haufenweise Hilfslinien, obwohl man als Fußgänger rein theoretisch an jeder beliebeigen Stelle die Fahrbahn betreten kann, um sie z.B. zu überqueren. Diese Hilfslinien führen dann wiederum zu total unsinnigen Routinganweisungen (übrigens ebenso für Radfahrer, wo sie noch verwirrender sind, da man deutlich schneller unterwegs ist) wie “In 20m rechts abbiegen und in 30m links abbiegen”, wenn man die Straßenseite wechseln soll und bilden meistens die Realität vor Ort überhaupt nicht ab (was schon an ihrer Natur als Hilfslinien liegt, die zugefügt werden um ein Routing zu ermöglichen, ohne, dass sie vor Ort existieren). Das widerspricht wiederum dem Grundatz, dass nur das Eingetragen werden soll, was vor Ort auch vorzufinden ist.

Oder aber, der Hilfsweg ist vergessen worden, was wiederum zu langen Umwegen führen kann, wie etwa beim Routing von diesem Way zu diesem Way

Nebenbei führt die Konevntion, Straßennamen nicht an parrallel laufende paths zu schreiben (was IMO auch vollkommen korrekt ist), dazu, dass die Fußwegführung so komplett ohne Straßennamen auskomemn muss.

Das Sidewalk-Tag bietet dagegen eine genauso breite Palette an Möglichkeiten zu genaueren Beschreibung des Gehwegs wie ein eigener Way, wenn man Werte wie sidewlk:right:smoothnes=excellent o.ä. nutzt.

Es gibt also schlicht keinen Grund, Gehsteige als eigenen Way auszugliedern. Und die Behauptung, dass das zu einem gerechteren Fußweg-Routing/mapping oder was auch immer führt, ist totaler Unsinn!

Viele Grüße

kreuzschnabel · 2017-09-26T11:04:18.000Z

hsimpson:

Das Sidewalk-Tag bietet dagegen eine genauso breite Palette an Möglichkeiten zu genaueren Beschreibung des Gehwegs wie ein eigener Way, wenn man Werte wie sidewlk:right:smoothnes=excellent o.ä. nutzt.
Es gibt also schlicht keinen Grund, Gehsteige als eigenen Way auszugliedern. Und die Behauptung, dass das zu einem gerechteren Fußweg-Routing/mapping oder was auch immer führt, ist totaler Unsinn!

+1. Gebe hsimpson in allen Aspekten recht. Das Mappen straßenbegleitender Fußwege als eigene Ways macht vieles umständlicher und bringt kaum Vorteile, abgesehen von der spontanen Sichtbarkeit der Wege auf Mapnik (aber das ist eine Frage des Renderers, ob er sidewalk=* auswerten will oder nicht). Das Erfassen als sidewalk=* am Haupt-Way ermöglichst flexibelstes Routing und die Ausgabe von Straßennamen im Routing, ohne diese eigens nochmal an den Way schreiben zu müssen (was von der Community AFAIS mehrheitlich abgelehnt wird).

Ich mache das nur, wenn wirklich was dazwischen ist, z.B. ein ausgewiesener Parkstreifen. Dann ist es wegen baulicher Trennung auch richtig.

–ks

hsimpson · 2017-09-26T11:24:31.000Z

kreuzschnabel:

Ich mache das nur, wenn wirklich was dazwischen ist, z.B. ein ausgewiesener Parkstreifen.
–ks

Ein Parkstreifen ist für mich auch keine bauliche Trennung, da es für den Fußgäger auch ohne weiteres Möglich ist, diesen zu durchqueren. Der Parkstreifen stellt dazu eine Verbindung der Straße und des Gehwegs dar, so kann man z.B. zu Fuß über den Gehweg zum Auto gelangen um dann den Weg über die Straße fortzusetzen. Daher halte ich die seperate Erfassung von Parkstreifen übrigens auch generell für falsch.

Übrigens: Man muss für Parkstreifen keine Schilder aufstellen. Viele Städte machen das zur Verdeutlichung, dass (nur) hier geparkt werden darf, aber eine einfache Markierung oder eine deutliche Absetztung gegenüber der Umgebung (z.B. durch einen Bordstein) ist rechtlich gesehen dasselbe.

Viele Grüße

hsimpson · 2017-09-26T13:06:55.000Z

Ich will noch kurz auf deine Links eingehen:

geri-oc:

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
Dort sind auch Beispiel verlinkt.

Das Propsal ist von 2011:
http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way

Wenn du schon aufs Wiki verweist, dann bitte auch vollständig:
https://wiki.openstreetmap.org/wiki/Key:sidewalk

Das Wiki hat das große Problem, dass man auf vielen Seiten zu bestimmten Tags keine Übersicht über die Alternativen bekommt und man daher schnell schließen könnte, dass der Tag die einzige Variante ist, wie man eine Situation beschreiben könnte.

Dazu wird leider nirgendwo im Wiki oder in dem von dir verlinktem Proposal beschrieben, wann was zum Einsatz kommt. Es wird immer nur beschrieben, wie man es einsetzen sollte. Die Beispiele im Wiki sind leider auch immer wieder mehrdeutig, sodass zwei verschiedene Tags auch gerne mal ein sehr ähnliches bis selbes Beispiel haben.

Von daher: Ja es ist korrekt, footway=sidewalk an einen Fußweg zu schreiben, wenn dieser als seperater Way erfasst wird (z.B., wenn Gehweg und Straße durch eine Hecke getrennt sind). Das sagt aber noch lange nichts darüber aus, ob man den Fußweg überhaupt als eigenen Way mappen sollte. Und da darüber nirgendwo eine eindeutige Aussage getroffen wird, gilt meiner Ansicht nach wieder die Grundregel, dass getrennte Ways nur dann in Frage kommen, wenn eine bauliche Trennung vorliegt.

Viele Grüße

geri-oc · 2017-09-26T13:15:35.000Z

hsimpson:

Oder aber, der Hilfsweg ist vergessen worden, was wiederum zu langen Umwegen führen kann, wie etwa beim Routing von diesem Way zu diesem Way

Du kannst nicht “Daten-Fehler” für falsches Routing verantwortlich machen.

Man sollte sich doch beim mappen an das WIKI als Grundlage halten. Dort ist das sidewalk:both;right;… gegenüber dem separaten Weg nicht einmal abgestimmt. Und nicht immer am “queren wo es möglich ist” festmachen, ein Rollstuhlfahrer kann das nicht. Wenn jemand von einem vorgeschlagenen sidewalk abweichen möchte, kann er das doch auch. Es gibt aber auch “Fußwege” die kein sidewalk sind und durch Geländer getrennt sind. Aber der “sichere” Fußweg sollte schon über abgesenkten Bordstein und Straßenquerungen möglich sein:

http://www.openstreetmap.org/directions?engine=mapzen_foot&route=51.05100%2C13.73477%3B51.04898%2C13.73791#map=17/51.04997/13.73626

http://www.openstreetmap.org/directions?engine=mapzen_foot&route=51.0025%2C13.7996%3B51.0079%2C13.8016#map=16/51.0053/13.7990

Das Argument alles an den hw der “Straße” zu mappen führt zu massenhaften Schlüsseln und Werten, die für ein Straßenstück ausgewertet werden müssen. Normalerweise müssten ja sogar für smoothnes, surface, access, … für jede Spur eingetragen werden, wenn dies zum routen herangezogen werden sollte.

Siehe dazu auch die lanes Diskussion http://forum.openstreetmap.org/viewtopic.php?id=59846 .

Wenn du damit sagen willst, die Erfassung von Gehwegen als sidewalk=left/right/both sei Fußgängerunfreundlicher, dann ist das totaler Unsinn.

Ich sagte nicht “Unsinn” - aber ungenau aus Sicht des Fußgängers. Siehe meine Gründe und vergleiche doch einfach einmal einige Fußwegrouten. Vielleicht auch einmal aus Sicht von Eltern für einen sicher Schulweg oder für jemanden, der mit Rollstuhl unterwegs ist. Und mappe das dann einmal für dein Gebiet zum Vergleich.

EDIT:

Wenn du schon aufs Wiki verweist, dann bitte auch vollständig:
https://wiki.openstreetmap.org/wiki/Key:sidewalk

Wie du aus der Schriftfarbe von sidewalk:: erkennst ist es ein Vorschlag - http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk

EinKonstanzer · 2017-09-26T13:26:19.000Z

Zurück zur Brücke an sich…

hsimpson:

Man kan alleine durch die geometrische Lage und korrekte layer-Angaben ohne Probleme erkennen, ob sich ein Element unterhalb einer Brücke befindet, auch dazu braucht es keine Relation.
…
Zusammengefasst: Nein, es ist durchaus erkennbar (auch für ein Programm), dass es sich hier nicht um 100, sondern um eine einzige Brücke handelt. Dafür braucht es keine (Sammel-)Relation.

Es wurde auch schon diskutiert ob man bei Adressen einfach Stadt, PLZ, Land weglassen kann, da das ja alles aus den PLZ-Grenzen rekonstruiert werden kann…
Von dieser Argumenation ist man schon lange weg!
Also zu prüfen ob etwas zufällig innerhalb einer geschlossenen Linie liegt (oder eines (Multi-) Polygons… Was zusammen gehört, gehört in eine Relation.

Und weiter…

Und was passiert mit Bank, Mülleimer, Haltestelle, Wartehäuschen,… auf der Brücke? Da müsste dann neben layer konsequenterweise auch ein bridge=yes daran. Oder „schweben“ die Objekte einfach so auf layer=1. Ohne bridge=yes gibt es ja dann keine Zuordnung zur Brücke… Die Bank im Wartehäuschen hat im Übrigen nicht mal ein layer-tag!

Daher ist eine Zuordnung der Objekte auf der Brücke zum Brücken-layer bzw. zur Brücken-Relation zwingend notwendig.
Und würden das die Router und Renderer das so fressen dann könnte man von einzelnen Elementen auf der Brücke, die Brückeninfo, layer und level entfernen und das einfach der Brück-Layer-Relation hinzufügen. Stichwort: Redundanzen vermeiden.

Als bridge=yes erfunden wurde (der Grundgedanke dazu) hat halt keiner daran gedacht, dass sich auch noch andere Dinge sich auf einer Brücke befinden können…
Wir sollten deshalb eher in layer denken. Auch eine Aussichtsplattform auf einem Turm ist eine Ebene für sich aber definitiv keine Brücke…

hsimpson:

Derzeit ist die Situation so, dass die Gleise unter der Brücke für die Brückenrelation aufgeteilt wurden, das halte ich für totalen Unsinn.

Da stimme ich zu 100% zu. Die Ebene hat nichts mit der Brückenebene zu tun.

Wir liegen gar nicht so weit auseinander…
Gleise raus aus der Relation. Wartehäuschen, Bank, … dazu. Der Brücke noch ein layer=1 verpassen und das Schnitzel ist gegessen.

PS: Die Diskussion über Fußwege/Bürgersteige ist in dem Betreitrag einfach falsch aufgehoben.

hsimpson · 2017-09-26T13:28:24.000Z

Also dein erstes Beispiel sähe nahezu genau so aus, wenn man den Gehweg als sidewalk erfasst hätte (z.B. entlang der Straße Altmarkt), dein zweites Beispiel aud jeden Fall.

Ein beidseitig abgesenkter Bordstein sollte mit highway=crossing und crossing=uncontrolled eingetragen werden. Das sollte ausreichen, um für Wheelchair-Mapping geeignete Übergänge zu finden.

Das Argument mit den vielen Tags an einem Way sehe ich definitiv nicht als Grund an. Für ein Programm sollte das überhaupt kein problem sein, ein paar Tags mehr auszulesen und der normale Nutzer von OSM-Daten kommt mit den Rohdaten ohnehin nicht in Kontakt.

Ein seperates Eintragen von ways als Bürgersteige birgt nunmal eine viel höhere Fehlerquelle. Um jede einzelne Routingmöglichkeit einzutragen müsste man ein ganzes Wirrwa von Wegen erfassen, die vor Ort alle nicht vorhanden sind. Das kann doch nicht gewünscht sein!

Grüße

hsimpson · 2017-09-26T13:41:33.000Z

EinKonstanzer:

Also zu prüfen ob etwas zufällig innerhalb einer geschlossenen Linie liegt (oder eines (Multi-) Polygons… Was zusammen gehört, gehört in eine Relation.

Ich sehe auch noch nicht wirklich den Sinn darin, dass alles zu einer Brücke zusammengehörig zu kennzeichnen. In der Realität macht es keinen Unterschied, ob es jetzt eine oder viele Brücken sind. Aber es interessiert weder bei Routing, noch beim Rendern oder wo auch immer.

EinKonstanzer:

Und was passiert mit Bank, Mülleimer, Haltestelle, Wartehäuschen,… auf der Brücke? Da müsste dann neben layer konsequenterweise auch ein bridge=yes daran.

Wozu denn? Was macht es für einen Unterschied zu Wissen, dass dieses Objekt auf einer Brücke steht oder nicht? Ein Teil der Beücke ist es ja ganz sicher nicht. Für das Routing reicht es aus, wenn direkt nebenan eine Straße mit demselben Layer langführt. Das ist ja auch das vorgehen, wenn ein Mülleimer mit (imlizitem) layer=0 über einem Tunnel steht.

EinKonstanzer:

Die Bank im Wartehäuschen hat im Übrigen nicht mal ein layer-tag!

Das ist natürlich ein Fehler.

EinKonstanzer:

Daher ist eine Zuordnung der Objekte auf der Brücke zum Brücken-layer bzw. zur Brücken-Relation zwingend notwendig.

Ich sehe darin keinen Mehrwert.

EinKonstanzer:

Und würden das die Router und Renderer das so fressen dann könnte man von einzelnen Elementen auf der Brücke, die Brückeninfo, layer und level entfernen und das einfach der Brück-Layer-Relation hinzufügen. Stichwort: Redundanzen vermeiden.

Es hat sich herausgestellt, dass solche Relationen kaum erfasst werden. Dazu sind sie unglaublich schwer zu warten und fallen immer wieder unerfahrenen Mappern zum Opfer, die sich damit nicht auskennen und die Relation zerstören.

EinKonstanzer:

Wir sollten deshalb eher in layer denken.

Da bin ich ganz bei dir. Layer=1 reicht vollkommen aus um die Lage eines Mülleimers auszudrücken. Da braucht es nichtmal die Einbindung in eine Relation

Grüße

hsimpson · 2017-09-26T13:46:52.000Z

Um es nochmal auf den Punkt zu bringen: Es macht für nahezu keine Anwendung einen Unterschied, ob das Gebilde jetzt als eine oder als 100 Brücken erkannt wird. Weder beim Routing, noch beim Rednern, und das sind IMO die beiden Hauptfälle für unsere Daten. Wenn man das unbedingt herausfinden will, reicht es vollkommen aus, die man_made=bridge-Area zu betrachten. Für die wenigen Anwendungsfälle, wo das tatsächlich relevant ist, finde ich es deutlich besser, dass das so erfasst werden muss, als dass wir unsere Daten mit noch mehr Relationen zukleistern.
Grüße

EinKonstanzer · 2017-09-26T20:34:47.000Z

Hi,
wenn ich etwas in das inden Mülleimer schmeissen möchte sollte der schon möglichst auf der selben layer-Ebene sein. Auf layer 0 wird stehts davon ausgegangen, dass der Mülleimer (von der Ebene her) immer erreichbar ist.

Hat man 2 Brücken mit jeweils einem Mülleimer nebeneinander (alle layer=1) dann ist es eben ein Trugschluss, das der Mülleimer von beiden Brücken aus erreichbar ist. Über eine Relation wird dann eindeutig festgelegt zu welcher Brücke was gehört. Betrifft alle weiteren Objekte (Bank, Haltestelle, Wartehäuschen, Bahnsteig, …) halt eben auch.
Also: Ganz wichtiges Thema 2018 Pass mal auf!

Ich habe soeben die Schienen aus der Relation genommen, die Brücke und die Umgebung exakt nach Kataster zurecht gezupft. Und sonst noch ein bisschen optimiert…

Muss da jetzt noch dringend etwas korrigiert werden oder können wir den Fall damit abhaken?

Grüße,
G.

Weide · 2017-09-27T10:26:09.000Z

EinKonstanzer:

Als bridge=yes erfunden wurde (der Grundgedanke dazu) hat halt keiner daran gedacht, dass sich auch noch andere Dinge sich auf einer Brücke befinden können…
Wir sollten deshalb eher in layer denken. Auch eine Aussichtsplattform auf einem Turm ist eine Ebene für sich aber definitiv keine Brücke…

Und genauso definitiv auch kein Layer!

“layer” ist keine Ebene. Gleiches “layer” bedeutet nicht “gleiche Höhe”. Verschiedenes “layer” bedeutet nicht “verschiedene Höhe”. “layer” hat nur eine Bedeutung für sich kreuzende Linien ohne gemeinsamen Punkt: In dem Fall und nur an der Kreuzungsstelle liegt das Objekt mit dem niedrigeren “layer” tiefer.

Weide