In meiner Stadt komme ich mit einer handvoll TRs aus.
Da kommt das Navi dann nicht so ins Schwitzen und der Akku hält länger. 
und manchmal kommt es auch vor, dass sie nicht für autos sondern für radfahrer relevant sind.
hier zum Beispiel meckert deine Karte rum:
http://map.comlu.com/?zoom=18&lat=50.101925&lon=8.687736&layer=OSM.de%20Style
als ichs korrigieren wollte viel mir auf, dass diese abbiegebeschränkung sich auf die radfahrer bezieht, die eben aus dieser straße rauskommen können.
Dann ist diese Abiegebeschränkung aber falsch getaggt. Ohne Begrenzung auf bestimmte Verkehrsarten ist das nicht erkennbar. Also setze restriction:bicycle=only_right_turn statt des einfachen restriction=* und es sollte gut sein. Diese Schreibweise ist laut Relation:restriction zulässig.
Ob diese Form von der Karte der Abbiegebeschränkungen erkannt wird oder gar von Rad-Routern beachtet wird, ist allerdings zur Zeit eine andere Frage.
Edbert (EvanE)
naja, die begrenzung ist in diesem fall nicht erforderlich, da autos ja eh nicht abbiegen können
(meine Meinunge) ansonsten kann man es natürlich so machen.
Wenn aus welchem Grund auch immer ein Auto daraus kommen würde, würde die Abbiegebeschränkung für dieses auch gelten?
Oder anders gefragt: Angenommen die Polizei beobachtet ein herausfahrendes, nicht rechtsabbiegendes Auto: Gäbe es nur eine Strafe wegen “Falschrum in Einbahnstrasse” oder auch wegen “Falsch abgebogen” (Roboter-Polizisten angenommen, sonst ist es ja eher willkürlich…)?
Es gibt Neues:
Die Icons werden jetzt rotiert angezeigt, so dass sie von der Orientierung her ungefähr der Abbiegerichtung entsprechen.
Programmiert hat das tyr_asd und mir hat das so gut gefallen, dass ich es auch sofort übernommen habe!
Danke!
Schön! Hier scheint ein Icon um 180° gedreht zu sein und ein anderes nicht ganz der Relation zu folgen- oder sind die Daten buggy?
http://map.comlu.com/?zoom=18&lat=49.341455&lon=7.146501&layer=Mapquest%20Open
Edit: zweites Icon ergänzt.
Besser jetzt?
Habe aber auch eins gefunden, das jetzt immer noch nicht passt. Werde das später analysieren.
Super, das ging fix. Sieht jetzt besser aus!
Hallo,
nochmal ein kleines Problem gefunden: http://map.comlu.com/?zoom=18&lat=49.250322&lon=6.860739&layer=Mapquest%20Open
Relation 1673762 führt in “rot = 90-Math.atan(dy/dx)*180/Math.PI;” zu einem “rot = NaN” wg. Division durch Null.
Nahmd,
Passiert bei Wegen in exakter Nord.Süd-Richtung.
Ersetze “Math.atan(dy/dx)” durch “Math.atan2(dy,dx)”. Dann frisst er auch dx=0.
Gruß Wolf
Das Problem saß bei mir vor meiner Tastatur 
Habe die falsche Node zur Berechnung herangezogen. Hier war’s dann zweimal die selbe Node, somit dx=dy=0. Jetzt sollte es besser sein.
Edit: @mmd: In der Nähe ist noch relation 1645007. only_right_turn, biegt aber links ab. Wenn du aus der Gegend bist, kannste ja mal vorbeischauen, was stimmt.
Jetzt sieht aber das Beispiel von oben (#52) wieder buggy aus. 
@netzwolf: Die atan2 Methode kannte ich auch noch nicht, wäre aber hier genau das richtige! (dann muss aber auch das nachfolgende “if (dx<0) rot += 180;” entfallen)
Da der ursprüngliche Mapper noch recht aktiv ist, habe ich ihn über PM kontaktiert.
Also im Gegensatz zu JOSM (der den from-Weg als Basis nimmt) ist hier der Zielweg entscheidend für den Winkel ?
Könnte man noch eine Warnung einbauen, wenn die Richtung nicht mit der Restriction matched ?
Beispiel: only_right_turn, der Winkel von from nach to ist aber ein “links-Winkel”.
Chris
Hallo Chris
Das wäre sicher erst mal als Warnung nützlich.
Die Router interessieren sich ja nur für only_* respektive no_* und betrachten ansonsten nur die Start-/Ziel-Wege und ggfs. den Via-Knoten/-Weg. Diese Diskrepanz deutet auf zwei mögliche Probleme:
- Die Beschränkung ist falsch benannt, aber die Start-/Ziel-Wege richtig gewählt.
Das ist ein ‘kosmetisches’ Problem, erzeugt aber kein falsches Routing. - Die Beschränkung ist richtig benannt, aber die Start-/Ziel-Wege falsch gewählt.
Das ist ein echter Fehler und führt damit zu falschem Routing.
Allein vom Betrachten der Karten-Daten kann man beide Fälle nicht unterscheiden. Mit Ortskenntnissen ist die Frage “falsche Bezeichnung oder falsche Wege” jedoch meist eindeutig zu beantworten.
Zusammengefasst wäre das schon ein wichtiger Hinweis, dort noch einmal nachzusehen.
Es gibt noch die Möglichkeit, dass no_* mit only_* verwechselt/vertauscht wurde, das dürfte (mEn) jedoch deutlich seltener als die anderen zwei Varianten sein.
Wo wir gerade beim Wünschen sind.
Wird auf ‘unnötige’ Beschränkungen (z.B. gegen eine Einbahnstraße) eigentlich hingewiesen? Das wäre ganz nett. Einerseits wäre das in der Form unnötig, andererseits kann das auf einen Fehler (z.B. falscher Ziel-Weg) hinweisen.
Und wie ist das mit falschen/fehlenden Rollen für die Mitglieder? Ich glaube, das wird aber schon als Fehler markiert.
Edbert (EvanE)
Ja das ist schon alles drin und ich habe bereits einige unnötige TRs entfernt.
Auf “Zielweg entgegen Einbahnstrasse” wird hingewiesen, dadurch habe ich einen der “Zielweg falsch gewählt”-Fehler gefunden.
Zumindest einen Hinweis auf fehlende Rollen habe ich schon gesehen.
mfg~ray
Hi.
Dann melde ich mich auch mal im Forum zu Wort. Erstmal: Klasse Karte.
Eine Kleinigkeit, die mir noch aufgefallen ist: Es gibt leider keine Möglichkeit, nur kaputte Turn-Restrictions anzuzeigen. Außerdem finde ich die Darstellung der Layer-Gruppierung für die TR-Overlays unglücklich; ein Layer-Tree wäre hier schön, so ungefähr:
|-show Turn Restrictions
|-correct TRs
|-TRs with warnings
|-TRs with errors
Einerseits wäre eine deutlichere Baumdarstellung schön, andererseits fehlt momentan die Option, TRs anzuzeigen, aber keine korrekten. Gerade dadurch wäre es aber als debug-Tool seeehr schön. Momentan muss man doch z.T. lange suchen, weil die kaputten TRs sich in den clustern verstecken und nicht als solche erkennbar sind.
Dabei gleich eine weitere Idee: Die Cluster könnte man optisch so gestalten, dass erkennbar ist, ob die geclusterten TRs okay/fehlerhaft/mit Warnungen sind.
Gruß
Peter
Einfach den Haken beim Overlay “Turn restrictions” entfernen, dann werden nur noch die mit Warnungen oder Fehlern angezeigt.
Die drei Overlays sind disjunkt. D.h. eine turn restriction ist nur in einem der drei Overlays, nicht in mehreren. T.r., bei denen Fehler erkannt wurden, landen im Fehler-Overlay. Wurden nur Warnungen ausgeteilt, landet die t.r. im Warnungs-Overlay. Alle anderen landen im “normalen” Overlay.
Geclustert wird pro Overlay, es gibt also zumindest schon mal keine gemischten Cluster. Die Cluster ändern je nach Anzahl der geclusterten Elemente die Farbe. Aber vielleicht sollte ich mal in dieses Cluster-Plugin eintauchen und einen Farbparameter einbauen, damit man erkennt, zu welchem Layer ein Cluster gehört … mla sehen … notiert ist es (aber etwas weiter hinten auf der TODO-Liste)