…und dann ist es noch immer ein Problem des Routers und dessen (mitunter falsch ausgewerteten?) Algorithmen und nicht das von OSM, und hat folglicherweiser hier nichts zu suchen! 
Dann bleibt halt keiner der aktuellen. Rechtlich ist *=destination kein kosten je meter Problem, wird aber weil es einfach ist zu einem Gemacht.
Defakto müsste man mit subgraphen arbeiten, oder artificial segments an den ein und ausgangsknoten die halt definierte Einmalkosten haben.
Aber wie gesagt das Thema führt in diesem thread zu weit.
Flo
Deine harte Aussage deckt sich nicht mit dem Englischen original das weisst du oder?
https://wiki.openstreetmap.org/wiki/DE:Bearbeitungsstandards_und_-konventionen
"Das Englische original ist hier Sinngemäß anders. Es spricht davon das getrennt gemapped werden kann (should) wo passend (appropriate). "
Deine (und anderer) harte position der trennung nur bei baulichen Trennung ist eine partikularmeinung der Deutschen Community und innerhalb dieser nur wiederum eines teils. Und durch immerwährende Diskussionen in den letzten 15 Jahren ist die ja auch nicht richtiger oder konsensfähiger geworden.
Wenn das Bestand hat müssten alle seperat gemappten Bürgersteige entfernt werden. Dort existiert keine bauliche Trennung (Für die Fußgänger) - nur um mal zu verdeutlichen was deine harte position an konsequenzen hätte.
Ich halte das, wie ich hier ja im Details ausgeführt, für nicht zielführend so zu mappen.
Darüberhinaus gibt genau an der Stelle Auf-/Abfahrten keinen Grund. Jedenfalls habe ich hier ausser das Thema Sonderrechte die potentiell wenden dürften keinen gehört.
Flo
Wo wir hier so schön bei geometrieen sind - Kann mir jemand erklären woher die Geometrie dieser Straße kommt? Also der Nördliche teil der einmündenden B55.
Also das Menschen mit dem Auto vielleicht so einen Bogen fahren mag ja sein. Aber wir mappen ja physische Straßen nicht statistische Fahrwege.
Natürlich kommt es hier wieder zu dem “links halten” “rechts halten” wenn man von süden kommt weil für den router das eine “Gabelung” ist. Ich würde den change also tendentiell reverten weil es nichts reales gibt was diese geometrie rechtfertigt, und dazu die Ansagen im Routing kaputt macht.
Aktuell nach änderung gestern
Vorher
So würde ich mappen
Östlich ist zwar keine Verkehrsinsel - aber ist die weniger befahrene Straße die dann einen Fehler beinhaltet. Einen Fehler muss man ja machen. Entweder man ignoriert die Verkehrsinsel, man baut kaputte geomtrieen oder man baut ein Dreieck in die weniger genutzte Straße.
Flo
Mir (als KISS - Mensch) gefällt die “vorher” Lösung am besten. 
1 Like
Ich finde alle 3 Lösungen okay – alle haben ihre Daseinsberechtigung. Persönlich würde ich wie die letzte mappen. Dass viele Abbiegungen wie “X halten” angesagt werden, ist eigentlich kein Problem, welches ich durch Geometrie lösen würde. Gab dazu mal einen guten Vortrag, wie man Kreuzungen besser zusätzlich als Flächen erfasst, um genau dieses Problem gut lösen zu können.
Die aktuelle Lösung erzeugt halt total kaputte ansagen im routing weil die Geometrie nicht stimmt.
Wenn du von Westen kommst kriegst du nichtmal ein “Rechts abbiegen” sondern ein “Geradeaus weiter” weil es keinen abbiegewinkel gibt.
Wenn du von Süden kommst bekommst du ein “rechts halten” weil es eine Gabelung ist.
Ich halte den aktuellen stand für maximal kaputt.
Flo
Ich würde auch Deine Variante bevorzugen, aber die Kreuzstraße nicht teilen, weil:
persönlich würde ich an der Stelle auch das erste bevorzugen aber die Linien weiter auseinander ziehen wie bei deinem Vorschlag für die Insel. Verstehe gerade nicht so ganz wo da fehlerhafte Routenansagen im Westen entstehen könnten, wenn man doch die Lanes hat mit turn instructions. Das müsste der Router doch dann eigentlich verwenden anstelle der Winkel Berechnung um “irgendwas selber anzugeben”
da sind wir wieder an dem Punkt realität vs “wir mappen nicht für router”. Wüsste ja mal gerne was TomTom, da in Zukunft zu sagt wenn sie mit den 3 Varianten irgendwas machen müssen oder die beiden anderen MagicEarth und Osmand . 
Diese “partikularmeinung” wir mappen nicht für Router sollte vielleicht mal Grundsätzlich überdacht werden, da gerade die 3 Navis mitlerweile doch auch einen Anteil an OSM Nutzern machen, welche auch für die Karten beitragen. Und nur aufgrund der “wir mappen nicht für router” Regel keine expliziten Tags oder Relationen einzuführen die in einem solchen Moment den Routern weiterhelfen würden und die OSM “Qualität” nochmal steigern würden im Auge der Nutzer ist halt irgendwie einen Teil seiner Nutzer vor die Wand laufen zu lassen.
Bei WAZE kann man analog zu unseren Abbiegebeschränkungen auch mitteilen wie der Router die Kreuzung ansagen soll. Was wäre daran so schlimm, eine solche Adaption auch anzubieten, damit die Router besser an komplexen Kreuzungen klarkommen, wo selbst mit Lanes und Turn angaben es nicht sauber zu lösen ist.
aus dem Kopf was es so gibt:
- nichts sagen
- Vorfahrtsstraße folgen
- links/rechts abbiegen
- links/rechts halten
- geradeaus fahren
Natürlich mappen wir für den Router. Und auch für den Renderer. Es geht bei dieser Aussage ja nur darum, dass wir nichts mappen, was nicht existiert, bzw. nicht falsch mappen, nur für den Renderer/Router. Von daher sollte der Satz mal umformuliert werden in „Wir mappen ja nicht extra falsch, nur für X“
2 Likes
Die Anbindung der Kreuzstraße ist in der 3. Version unglücklich. Mit den zwei Ästen kann ich leben, aber nicht mit dem Abbiegewinkel von der Kreuzstraße nach links auf die B 55. Wenn man dem südlichen Ast das oneway wegnimmt, geht es.
Die Kreuzung ist nicht gerade, sondern versetzt, die Kreuzstraße mündet südlicher als die B 55. Das war an der alten Version schlicht falsch.
Bitte? Wenn du von Westen kommst und rechts abbiegen willst, gibt es genau an der richtigen Stelle einen 90°-Winkel.
Ich kenne kein Navi, das so was sagt, und ich bin schon oft mit Navi über so gemappte Kreuzungen gefahren. Ich hab grad mit ME eine baugleiche Kreuzung probiert, er sagt sauber “links abbiegen” bzw “geradeaus”. Aber wir können den Abbiegewinkel gern steiler machen und auf einen eigenen Node legen. Ich lerne ja gern dazu, auch wenn ich bei Breitseiten wie “maximal kaputt” erstmal durchatmen muss.
Zu den beiden Ausgangsfragen (Auflösung / bauliche Trennung):
Gerne so rund wie möglich mit vielen Nodes. +1 zu FraukeLeo
Gerne die bauliche Trennung so strikt wie möglich umsetzen, nur nicht bei Verkehrsinselzickzackkursen wenn mehrere Inseln aufeinander folgen - also sehr ähnliche Sichtweise wie Galbinus.
Zum Thema Kreuzungsgeometrie/Ansagen:
=> Favorit 1 (die Linien so legen wie die Mittelinie der einzelen Spuren asphaltiert ist) siehe flohoff-Bild1
=> zweitbeste Variante siehe flohoff-Bild 2 ähnlich wie es vorher war aber die nicht separate Linie der B58 etwas weiter südlich, siehe AB-Bild 1 unten.
=> drittbeste Variante siehe flohoff-Bild 2 genau wie es vorher war
=> viertbeste Variante mein AB-Bild 2
=> fünfbeste Variante siehe flohoff-Bild 3 ähnlich zu googles Bild: Google Maps (würde hier etwa von google abgemalt werden wollen? - Mappt google etwa auch für die Navi-Ansagen?)
AB-Bild 1
AB-Bild 2
Ich verstehe das Argument von flohoff bzgl. Einfachheit entsprechend so wenige TR wie möglich zu setzen, aber es gibt für die notwendigen TR’s allerdings bereits eine Menge an QA-Tools:
- abrenschs: BRouter Suspect Manager (https://brouter.de/brouter/suspects)
- zartbitters: Map of Turn Restrictions by Zartbitter - Turn Restrictions - OpenStreetMap
- flohoffs eigene (Könntest du die Issues auch veröffentlichen, sodass die Community beim Korrigieren helfen könnte?)
Von dem Mapping für die Routeransagen halte ich nicht viel, ich würde nicht proaktiv dagegen zeichnen aber nicht das reele Kartenbild nur deswegen verbiegen, damit die Ansagen passen.
Welche Software würde deiner Meinung falsch ansagen?
Die bauliche Trennung zwischen einem Bürgersteig und der Fahrbahn besteht in dem Bordstein, was übrigens auch die bauliche Trennung zwischen einer standardmäßigen Verkehrsinsel und der Farhbahn darstellt. Ein Bordstein ist physikalisch etwas deutlich Anderes als eine aufgemalte Linie.
Es ist für normale Fußgänger keine physische Hürde. Das ist aber die argumentation bei der Baulichen Trennung im Autoverkehr.
Flo
Die Diskussion hierüber sollte vielleicht eher im Wiki geführt werden. Ob und wann baulich nicht getrennte Spuren separat erfasst werden sollen, können wir gerne abstimmen lassen, um herauszufinden, was und wie groß der Konsens der deutschen Community ist. Aber ich bin mir sicher, Du kennst das Ergebnis bereits 
Routingansagen sind IMMER abhängig des Winkels zwischen den Wegen.
Hast du einen Spitzen Winkel ist es “rechts halten” “links halten” - Ist es ein halbwegs rechter winkel ist es “rechts abbiegen” “links abbiegen” - Ist es nur ein geringer winkel kommt gar nichts weil es ja geradeaus geht.
Es geht um diesen Winkel
Es gibt dann 2 Fehler -
- Die Ansage kommt an der falschen Stelle - Hier kommt sie an der Einmündung nicht an der Ausfahrt
- Die Ansage ist “links halten” nicht “links abbiegen” als wenn die Straße sich Gabelt
Beispiel - Ebenso designte Kreuzung - “keep left” … Da ist aber keine Gabelung sondern eine Kreuzung und die Ansage muss heissen “Links abbiegen” - Das wird aber durch die kaputten Winkel vereitelt.
Graph hopper:
" 2. Keep left and drive toward Lemgo, Blomberg, Warburg, Peckelsheim, Brakel"
Wenn man anders herum fährt hat man einen sauberen Winkel - Da ist es dann “Rechts abbiegen”.
" 2. Turn right onto B 64 and drive toward Paderborn, Bad Driburg"
Da gilt im übrigen für alle Einmündungen gleichermaßen - Hier einfach mal 2 Straßen die halt “Spitz” ineinander münden. Winkel sind WICHTIG für das Routing. Das einfach lieblos im Spitzen Winkel aneinanderkleben “Passt scho” führt halt in den Navigationsansagen zu einem ständig brabbelnden OSMAnd und Co “Links halten” “Rechts halten” “Hauptstraße weiter auf Hauptstraße”.
Hört ihr euch NIE die Ansagen von OSMAnd und co an? Wenn man nur zuhört findet man Tonnen an Geometriefehlern. Wenn da Ansagen kommen und es geht nur geradeaus ist was in der Geometrie kaputt. Wenn da kommt “Rechts halten” kommt obwohl da nichts ist ist da eine kaputte Einmündung.
Flo
Ich weise nur drauf hin das hier mit zweierlei maß gemessen wird bei Fußwegen und Fahrspuren. Und nein - das Ergebnis kenne ich nicht. Wir können gerne mal raussuchen wo die Abstimmung ist für die veränderung der “Best practices” gegenüber dem Englishen original ist.
Internationaler Konsens ist das mal definitiv nicht wie wir sehen. Und auch in D ist das nicht konsens. Es gibt gute gründe das im Englishen original “should … where appropriate” steht - Das dann in Deutschland jemand ohne Abstimmung das verschärft hat mag ja sein - Konsens wird das dadurch noch lange nicht in der Absolutistischen Art.
Und wir reden hier nicht von “Kann beliebig getrennt gemapped werden” oder “Soll immer getrennt gemapped werden” sondern zurück zum Englischen original “should … where appropriate”
Flo
Nur so eine Idee (vermutlich noch nicht zu Ende gedacht), könnten die Ansagen anstatt abhängig vom Winkel, nicht auch abhängig vom betreffenden turn(:lanes)=*-Parameter gemacht werden?
turn:lanes=left|none => “links abbiegen“
turn:lanes=slight_left|none => “links halten“
Ja, der Naviton ist bei mir immer stumm gestellt!
Ich beschreibe nur das was aktuell ALLE Navigationssysteme machen - Und hier gibt es oft auch keine lanes - Was machst du dann?
Man kann das nicht überall hinten - Man muss die Winkel sauber halten.
Hier noch das Beispiel mit “continue on …” oder “weiter auf …” - Und hier hast du keine lanes …
Gabelung - es soll “eher die geradeaus straße” genommen werden - Also wird mit “Weiter auf …” eine Ansage gemacht.
Seit 10 jahren gucke ich mir so zeugs systematisch in der RouteQA an und korrigiere so zeugs ständig. So ist ja auch dieser Thread entstanden weil ich so zeugs mal wieder weggeräumt habe.
Flo