Hab die lanes nach bing gefixt und noch zwei TRs eingebaut.
–ks
Also der Eingangspost von Win32netsky bezieht sich eindeutig auf Garmin und darauf wurde dann mehrfach eingegangen und die Änderung wurde auch für Win32netsky für die Verwendung von Garmingeräten durchgeführt, da nur der monierte nördliche Teil der AS Klinga so geändert wurde dass sein Problem gelöst wird und alles andere wurde nicht berücksichtigt.
Hier geht es nicht einfach darum “die Kreuzungsgeometrie” abzubilden, sondern darum eine Lösung für einen bestimmten Router zu finden.
Das Zusammenlegen der Auf- und Abfahrten an Anschlußstellen oder nach der Aufspaltung in Einbahnstraßen um Verkehrsinseln in Kreuzugsbereichen auf einen Punkt ist gängige Praxis.
Ich lasse derzeitig Mapfaktor Navigator immer im LKW-Modus laufen, am Wochenende waren es ca. 1200 km von Slano - Kroatien über Slowenien und Österreich nach Deutschland, solche Probleme wie sie von Win32netsky geschildert werden habe ich da nicht bemerkt.
Wenn eine spitze Einmündung, um die man mit dem LKW nicht herum kommt, gebaut wird (weshalb auch immer ???), steht da auf jeden Fall auch ein Schild, dass da kein LKW lang soll. Wenn an einer solchen spitzen Einmündung kein Schild stehen sollte, dann muß der Fahrer des LKW für sich im Einzelfall immer noch einschätzen können ob er da im Rahmen der physikalischen Gesetze lang fahren kann.
Wenn wie von Win32netsky gefordert die Wendemöglichkeit an Anschlußstellen zu erhalten hat auf keinen Fall noch etwas mit Routing zu tun, sondern geht schon ehr in Richtung böswillige Mißachtung der Straßenverkehrsordnung, ab und zu sollte man sich die StVO und StVZO mal durch lesen ( § 32d Kurvenlaufeigenschaften,StVZO )
Ich bin aber auf keinen Fall ein Gegner von Win32netsky, ich schätze sein Projekt und habe große Achtung vor der Leistung der Brummifahrer, da ich vor langer Zeit auch mal am “großen” Lenkrad drehen durfte.
Die Erfassung von Daten für das LKW-Routing lässt oft noch zu wünschen übrig, daran sollten wir arbeiten.
Senni
Dieser Thread wurde dadurch ausgelöst, daß es auf einem Garmin-Gerät auffiel. Naturgemäß liegt dann darauf ein thematischer Schwerpunkt der Diskussion. Das heißt aber doch nicht, daß es nur Garmin-Geräte beträfe.
Mir haben auch andere Navi-Apps (AFAIK war es MapFactor Navigator, im PKW-Modus) auch schon mehrmals die Abbiegeanweisung „scharf nach rechts abbiegen“ (oder sinngemäß) ausgegeben, wenn es tatsächlich einfach nur rechtwinklig nach rechts ging. War eine ähnliche Stelle, eine Einmüngung eines hw=residential, auch spitz mit der naheliegenden Einfahrt zusammengemappt. Das führt in dem Fall zwar nicht zu geändertem Routing, aber doch immerhin zu einem irreführenden Abbiegehinweis. Wenn an selber Stelle noch ein weiterer Weg spitzer einmündet, kann man sich da durchaus verfahren.
Es geht also grundsätzlich nicht nur um Garmin, auch wenn das Problem, das diesen Thread ausgelöst hat, auf Garmin auftrat.
Andere Frage: Welchen Nachteil siehst du denn darin, Anschlussstellen mit passender Kreuzungsgeometrie zu mappen? Wenn es keinen gibt, warum sollten wir es dann nicht machen? Ich finde es unterm Strich besser als das Zusammenführen auf einen Punkt – einfach deshalb, weil die tatsächlichen Fahrspuren sich auch nicht an einem Punkt treffen. Es bildet die tatsächliche Kreuzung also wirklichkeitsgetreuer ab. Wenn die Ein-Punkt-Methode gegenüber der Zwei-Punkt-Methode Vorteile bietet (gut: ein Node weniger), dann können wir das diskutieren, aber wenn sie es nicht tut und die Zwei-Punkt-Methode Vorteile im Routing bietet, und sei es auch nur für ein System, dann verstehe ich nicht, wieso wir das nicht anwenden sollten. Von Vorteilen müssen doch nicht immer zwingend alle profitieren; erst wenn andere Systeme einen Nachteil davon hätten, wäre es eine einseitige Bevorzugung.
–ks
Also ich sehe keinen Nachteil in der dargestellten Methode und habe das auch sehr lange praktiziert, mußte dann aber feststellen, das nach mir oft wieder auf die Einpunktmethode umgemappt wurde und habe mich dem dann stillschweigend unterworfen.
Meine größten Gegner waren dabei die “Einbahnstraßen-um-Verkehrsinsel-Mapper”
Senni
Dann sollten sich doch bitte diejenigen, die es danach wieder umgemappt haben hier äußern. Mir erschließt sich der Sinn der Einpunktmethode nämlich nicht, die geäußerten Nachteile der Methode sehe ich dagegen ein.
Baßtölpel
D’accord, die sind furchtbar. Kleine Verkehrsinseln werden als Streckenabschnitt mit traffic_calming=island gemappt. Ansonsten braucht man abgesehen von den Einbahnstraßen auch noch zwei Wendeverbote. Vollkommen überflüssiger Datenmüll ist das.
Ich finde sogar, daß wir kleine (wenige Meter) Verkehrsinseln an Kreiselabfahren nicht unbedingt mit aufgegabelten Ways mappen müssen. Oder winzige Inselchen in der Größenordnung 2 Meter links von ebenso kurzen Rechtsabbiegerspuren an T-Kreuzungen. MapFactor sagt mir dann immer „biegen Sie leicht rechts ab, dann biegen Sie rechts ab“. Da könnte man auf die Rechtsabbiegerspur getrost verzichten.
Nachtrag: Die Ein-Punkt-Methode ist genau dann schöner, wenn eine separate Rechtsabbiegerspur da ist. Dann fährt ja nur der linksabbiegende Verkehr sowohl von der einmündenden Straße als auch in die einmündende Straße über den einen Punkt, und die beiden Wege sind „ausgerundet“. Ist aber keine separat gemappte Rechtsabbiegerspur da und müssen Rechtsabbieger von der einmündenden Straße demnach auch über den einen Punkt, wird es nachteilig – und das war ja in Klinga der Fall.
–ks
@sennewald63 Ein paar Hinweise zu Garmin: wir haben keine Tools von Garmin, sondern unsere Werkzeuge, um Garmin-Karten zu erstellen, entstammen reverse engineering; unsere Karten haben ein altes Format, das von aktuellen Geräten noch einigermaßen unterstützt wird, und nicht etwa ein aktuelles Garmin-Format.
Ich kann mich erinnern, daß spitze Winkel mal ein Thema in der Mailing-List zu mkgmap (dem Tool zu Kartenerstellung) waren. Garmin vergibt einen Malus bei spitzen Winkeln. An Details erinnere ich mich nicht, aber es gab wohl auch ein paar Patches, z.B. http://gis.19327.n5.nabble.com/Patch-v0-fix-sharp-angles-to-optimise-bicycle-routing-td5852950.html
Das mappen von Verkehrsinseln an Kreuzungen, Einmündungen und Kreisverkehren als einfacher Way mit traffic_calming=island sehe ich auch als richtig an und setze es auch um.
Zunehment sind aber “Micromapper” aktiv, die eben auch solche kleinen Verkehrsinseln mit massig Punkten so genau wie möglich darstellen wollen wie z. Bsp. hier http://www.openstreetmap.org/#map=17/51.30779/11.23673 oder hier sogar mit einzelnen Bäumen http://www.openstreetmap.org/#map=17/51.42933/11.39132 .
Im zweiten Bsp. habe ich den Way der Abfahrt mal durch die Insel gezogen und es stört nichts, denn wir zeichnen ja den Vektor der Straße und beschreiben dessen Eigenschaften.
Die Genauigkeit diese Micromappens hat nichts mehr mit Geodaten zu tun, sondern geht in Richtung CAD , es bringt keinen “Mehrwert” und die Wartung der Daten muß auch sichergestellt werden.
Die Frage “Wie schützt man tagging gegen “Korrektur” von tagging ?” wird in kommender Zeit wohl genauer zu beantworten sein.
@Bernhard Hiller, danke für die Info zu mkgmap und dessen Entstehung, ich habe mich darauf hin auch mal noch ein wenig schlauer gemacht.
Hallo Senni,
Diesem “Mikromapping” wird man sich nicht verschließen können… Ich sehe das als normalen Lauf der Dinge an. Letztendlich läuft es mittel- bis langfristig daraufhin aus, daß es getrennte (Erfassungs-)Ebenen geben wird, die einerseits nur für das Routing da sind und andererseits für die reine Kartendarstellung.
Ich sehe das nicht als Problem an, Straßen an solchen Inseln aufzuteilen… Es ist meiner Ansicht nach eine Sache des Routers, damit entsprechend umzugehen (die viel geliebte OnTheGround-Regel). Was ich aber beobachte, einige Mapper verfallen allzuleicht zum Setzen unnötig vieler Abbiegebeschränkungen.
Auch bei Kurven kann der eine oder andere Punkt mehr nicht schaden, es ist eben eine Kurve. Leider kann OSM keine Splines… dann wären mit weniger Punkten bessere Kurven möglich. Wir mappen zwar nicht für den Renderer, es soll sich aber zu mindestens für das Auges des Betrachters ein angenehmes und schlüssiges Kartenbild ergeben.
Mit “die Wartung der Daten muß auch sichergestellt werden” hast du recht, darum würde ich Relationen nur da einsetzen, von es nötig ist. In deinen würde ich geschätzt mit einem drittel bis einem viertel an Relationen auskommen.
Im übrigen fehlen einige an turn:lanes:= an den Straßen.
Sven
Sven,
dann schreib uns doch bitte welche der 4 Abbiegerelationen an der Abfahrt Heldrungen
( http://www.openstreetmap.org/#map=17/51.30779/11.23673 )
oder der 5 Abbiegerelationen an der Abfahrt Allstedt ( http://www.openstreetmap.org/#map=17/51.42933/11.39132 )
erhalten bleiben können.
Ich auf jeden Fall und bestimmt auch andere die hier mitlesen sind noch lernfähig.
Das an einigen Kreuzungen so manche Abbiegerelationen zu viel ist habe ich auch schon gesehen und oft scheinen auch Wendeverbote vom Himmel zu regnen.
Senni
Ich heiße zwar nicht Sven, aber ich würde alle erhalten. Aber etwas anderes finde ich unschön: diese Praxis, Beschleunigungsstreifen erst 100 m weit parallel zu führen und dann plötzlich im 45°-Winkel auf den Fahrstreifen zu führen. Erstens sieht es scheiße aus (gut, ist Geschmacksache), zweitens ist es Spurmapping, drittens verleitet es Navis am Anfang des Beschleunigungsstreifens zu der unsinnigen Ansage „in 100 Meter biegen Sie rechts auf die Autobahn ab“, weil das Navi am shared node eine Richtungsänderung um 45° sieht.
Ich führe an solchen Stellen die Ways von da, wo die Fahrbahnen sich physisch vereinen (also die Kurve aufhört) in schön flachem Winkel zusammen, fertig. Verzögerungsstreifen entsprechend umgekehrt.
Sehr beliebt bei Kreiseleinfahrten: no_left_turn an jeder Einfahrt. Ich liebe es. Am besten noch ein no_u_turn auf dem Kreiselway an jeder Ausfahrt. Oder gleich an jedem Node, da darf man ja auch nicht wenden.
–ks
Ich nehme mal Heldrungen… An der L222 sind ja turn:lanes:= erfasst. Hier sind zwei der vier restriction=only_straight_on die L222 betreffend eigentlich überflüssig, turn:lanes:forward=through definiert, daß du hier nicht abbiegen darfst. Zum Beispiel braucht diese Relation hier: https://www.openstreetmap.org/relation/3996011 nicht mehr gesetzt werden. Ich vermute aber mal, daß diese aber auch nicht schadet…
Sven
Ja, ich hatte schon einen Kreisel mit 39 (!!) Abbiegebeschränkungen (meist no_u_turn) … Kreisel war entsprechend fragmentiert. Mein bisheriger Rekord. …und zu guterletzt Landuse an den Highway geklebt… Das war ein “Spaß”… Zum Glück kannte ich den Verursacher… Kurze PN und die Sache war geklärt.
Sven
Hallo Sven,
du hast zwar die Anschlußstelle verwechselt aber dein Argument mit turn:lanes:*=through verstehe ich, das “nur gerade aus” ist damit ja schon definiert.
Senni
@
Tatsächlich verwechselt… ja, ist aber egal. Mit konsequenter Anwendung von turn:lanes*=* erübrigen sich einerseits viele Abbiegebeschränkungen es lassen sich auch solche Anschlußstellen meiner Meinung nach hinreichend geometrisch sauber modellieren.
Grundsätzlich meine ich auch, daß vor allem Router solche Informationen auszuwerten haben. Da bin ich aber auch guter Hoffnung, das das auch geschieht.
Sven
Turn(:lanes) sind bislang rein kosmetisch.
Sicher?
http://wiki.openstreetmap.org/wiki/Key:turn:lanes
Osmand unterstützt es… und andere Router sollten sich auch langsam Gedanken machen…
Sven
Auch MapFactor Navigator mit OSM-Material liefert zuverlässige Fahrspurassistenz, wo turn:lanes gemappt ist. Insofern verstehe ich Jojo4us Bemerkung nicht einmal ansatzweise. turn:lanes ist sehr praxisrelevantes Tagging, wird von gängigen Routern ausgewertet und von mir gemappt, wo es nur geht, was das Zeug hält. Ich sehe ja unterwegs, wo es noch fehlt 
–ks
Ich meinte kosmetisch im Sinne von “ersetzen keine Abbiegerelation sondern zeichnen schöne Pfeile”.
Wenn ich an einer geradeausführendenen Straße mit je einer Stichstraße nach rechts und nach Links ein turn:lanes:forward=left|through gesetzt habe, brauche ich (eigentlich) keine weitere Abbiegerelation, die ein mögliches Rechtsabbiegen verhindert. Diese ist hier dann unnötig, da die Wegeführung bereits durch turn:lanes:= vorgegeben ist; natürlich vorrausgesetzt, daß turn:lanes auch ausgewertet wird. Abbiegerelationen werden in der Hauptsache erst dann nötig, wenn in betreffender Fahrtrichtung keine getrennten Fahrspuren da sind (wenn sie real da sind, aber nicht erfasst worden sind, bzw. real das durch entsprechende Schilder gekennzeichnet ist)
Sven