OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#1 2017-10-01 19:47:32

abrensch
Member
Registered: 2013-01-07
Posts: 317

QS Fernwegenetz

Hab heute die Zahl meiner Changesets mehr als verdoppelt...

Anlass war, dass ich beim Test von Auto-Routing immer wieder zufällig auf Connectity-Fehler stosse, und zwar fast immer nach einem simplen Muster:

- oneway-dead-ends: kurzes falsches oneway-stück zerschneidet eine Fernstrasse

- no-access-nodes auf Fernstrassen statt wie gewollt für die abzweigende Strasse

Dann hab ich mir gedacht, nach solchen simplen Muster kann man auch mit dem Treibnetz fischen, und tatsächlich hat mein Scanner nur etwa 70% false-positives gebracht, 30% waren also echte Issues.

Das ist soviel, dass ich das erstmal auf das Autobahn- und Bundesstrassen-Netz beschränken musste.

Wenn man da runter geht auf secondary, tertiary, ... dann werden das ziemlich viele suspects, und wenn man dann noch über Deutschland hinausgehen will,  dann ist das ohne einen spezialisierten Issue-Tracker garnicht mehr machbar.

Jetzt hab' ich schon angefangen, selbst einen Issue-Tracker dafür zu bauen, was zwar garnicht so abwegig ist, aber irgendwie wahrscheinlich auch Unsinn, weil gibt ja schon solche Issue Tracker (MapRoulette,...)

Ich weiss aber nicht, ob man da automatisch generierte Suspects reinkippen darf, oder ob das manuell bestätige Issues sein müssen. Wer hat Rat und kann mich von der Idee eines spezialisierten Issue-Trackers speziell für diese Connectivity Bugs abbringen?

Danke und Gruss, Arndt

Offline

#2 2017-10-02 18:12:20

Nakaner
Member
Registered: 2011-09-03
Posts: 1,763
Website

Re: QS Fernwegenetz

Hallo Arndt,

kannst du mal bitte ein paar Beispiele für die von dir genannten Fehler nennen? Wenn ich wüsste, wonach man suchen müsste, könnte ich die QA-Tools, an denen ich mitarbeite, ggf. erweitern.

abrensch wrote:

Ich weiss aber nicht, ob man da automatisch generierte Suspects reinkippen darf, oder ob das manuell bestätige Issues sein müssen. Wer hat Rat und kann mich von der Idee eines spezialisierten Issue-Trackers speziell für diese Connectivity Bugs abbringen?

Ich denke, dass Martijn van Exel als eine der Personen hinter Maproulette die Frage am Besten beantworten kann. Die Aufgaben in Maproulette sind automatisch erzeugt, jedoch weiß ich nicht, ob sie eine niedrige False-Positive-Quote haben oder nicht.

Viele Grüße

Michael


Bitte aussagekräftige Threadtitel verwenden und bei Änderungssätzen einen aussagekräftigen Kommentar eingeben.

Offline

#3 2017-10-02 21:17:17

R0bst3r
Member
Registered: 2015-04-23
Posts: 349

Re: QS Fernwegenetz

Im Prinzip reicht für MapRoulette eine GeoJSON.
Wenn das Projekt richtig beschrieben wird, muss der Benutzer false positive erkennen oder Fehler beheben.


Manchmal muss man einfach mal machen ...

Offline

#4 2017-10-03 14:24:59

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

Nakaner wrote:

kannst du mal bitte ein paar Beispiele für die von dir genannten Fehler nennen? Wenn ich wüsste, wonach man suchen müsste, könnte ich die QA-Tools, an denen ich mitarbeite, ggf. erweitern.

Hab' meinen Poor-Mans tracker jetzt online und kann Dir jetzt über tausend Beispiele nennen:

http://brouter.de:443/brouter/suspects

(Ja, http auf Port 443...)

(Ja ich weiss, die Liste muss eine Karte sein, aber das krieg ich auf die Schnelle nicht hin...)

Die Suchregel hab' ich jetzt noch verallgemeinert: Jedes "tote Ende" auf einer Fernstrasse (>= secondary) ist ein suspect.

Also immer dann, wenn man auf einer Fernstrasse zu einem Node routen kann, an dem es dann nicht mehr weiter geht. Ob das jetzt durch Einbahnstrassen, Sperrknoten, Abbiegebeschränkungen, echte Sackgassen, Sperrungen an Wegen etc. passiert unterscheide ich nicht mehr.

Als echte Issue sehe ich dann aber nur die, wo tatsächlich das Routing gestört ist. Also wenn der suspect durch eine Unsauberkeit getriggert wurde, z.B. one-way nicht auf dem gesamten betroffenen Abschnitt, dann ist das false-positive, auch wenn man es theoretisch bereinigen könnte.

Da geht natürlich auch die Logik des Routing-Profils ein. Z.B. sperrt bei BRouter ein barrier=lift_gate für Autos auch implizit (ohne access=no). Wenn jetzt jemand einen Bahnübergang so tagged (das tun die!), dann ist die Strasse gesperrt. Oder ich hatte  access=military nodes aufder A73 bei Bamberg gefunden, und das stand da seit Jahren. Wahrscheinlich haben andere Router es einfach nicht beachtet.

Aber die meisten Issues sind so verbastelte Einbahn-Strassen oder Abbiege-Beschränkungen. Aber es sind natürlich auch echte, gewollte Sperrungen dabei, dann steht's ja aber hoffentlich als note in der OSM Datebank.

Mein Poor-Man tracker benutzt jetzt noch den Zwischenstatus "confirmed". Weil nach meiner Erfahrung sind es zwei getrennte Arbeitsschritte (ggf auch verschiedene Personen)

- die suspects sichten, um die echten Issues zu finden
- die echten issue bearbeiten

Drückt man auf "confirmed" bei einem Issue, dann steht das Alter der confirmationin der Liste. Sieht man da also einefrische confirmation, dann kann man davon ausgehen, dass es sich jemand anders gerade anschaut.

Bei "mark as confirmed" und "mark as false-positives" mache ich eine Gegenprüfung, ob tatsächlich für genau dieser Gegend (+- paar hunderd Meter) kürzlich mehrere routing requests am BRouter-Web Server ankamen. Damit hoffe ich, dass die false-positives dann auch wirkich stimmen, es sich jemand also wirklich angeschaut hat, also den Kreisel von jeder in jede Richtung geprüft hat.

Ich hab' die Liste geographisch sortiert (ja, ich weiss, das muss eine Karte sein...) , um es bisscchen einfacher zu machen, gezielt eine Gegend zu bearbeiten. Primär ist das nach 1*1 Grad Quadraten sortiert, und innerhalb der Quadrate dann von west nach ost.

Innerhalb eines solchen Qudrates sind es dann nurnoch wenige Dutzend Issues, also genau die Richtige Menge für einen verregneten Nachmittag...

Nakaner wrote:

Ich denke, dass Martijn van Exel als eine der Personen hinter Maproulette die Frage am Besten beantworten kann. Die Aufgaben in Maproulette sind automatisch erzeugt, jedoch weiß ich nicht, ob sie eine niedrige False-Positive-Quote haben oder nicht

Maproulette  schau ich mir an, vielleicht passt das da rein. Aber ich hab auch OSMSuspects gesehen und auch das Ding von der Geofabrik, das ist ja auch eigentlich genau für sowas gemacht.

Offline

#5 2017-10-03 15:59:54

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 502

Re: QS Fernwegenetz

Hallo,

ich habe mir die "Fehler" in meiner direkten Umgebung angeschaut und wollte diese als "falsche Fehler" melden. Das funktionierte aber nicht.
Es handelt sich um folgende Straßen / 'Stellen:
1.) http://brouter.de/brouter-web/#zoom=16& … le=car-eco
2a.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco
2b.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco

Bei beiden Straßen handelt es sich um Sperrungen wegen Baustellen / Neubau.
Den Stummel der alten B 311 (1.)) habe ich heute noch auf vehicle=destination bzw. vehicle=no gesetzt.

Grüße aus Oberschwaben
Peter

Offline

#6 2017-10-03 16:14:11

fx99
Member
From: Baden-Württemberg
Registered: 2009-06-02
Posts: 1,224

Re: QS Fernwegenetz

Wird sowas nicht schon durch OSMI abgedeckt?
http://tools.geofabrik.de/osmi/?view=ar … _same_tags

Offline

#7 2017-10-03 16:26:14

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 502

Re: QS Fernwegenetz

fx99 wrote:

Wird sowas nicht schon durch OSMI abgedeckt?

Was ?

Offline

#8 2017-10-11 22:38:46

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

Nächste Runde...

weil der osm-planet seit 2 Wochen klemmt, habe ich die Liste der "suspects" (im Sinne von offenen Enden für >= secondary) auf Basis des germany-extracts (geofabrik) refreshed.

Das auf einem extrakt zu rechnen hat den Nachteil, dass dabei zusätzlich offene Enden entstehen an der Grenze des extrakt-polygons. Die liegen aber alle im Ausland.

Also in der folgenden Liste die ausländischen suspects nicht weiter betrachten:

http://brouter.de:443/brouter/suspects

da ist ein Rechteck im Westen Deutschlands (von 48/7 bis 55/10 ) flächendeckend bearbeitet. Der wilde Osten fängt aber schon am 10. Längengrad an. Und im äussersten Süden <48 Grad sind auch noch issues.

Es gab in der Vorgängerliste eine Klasse von Fehlern mit Turn-Restrictions, bei dem das from-Member den via-Node bicht beinhaltet - das war ein Fehler in brouter, weil diese TRs sind ja definitiv kaputt - solche DInger sollten jetzt nicht mehr dabei sein.

Was noch bisschen blöd ist, dass Knoten-Fehler oft 3-mal erscheinen, für den Knoten selbst und die beidern blockierten Wege.

Beim Thema cycle_barrier oder lift_gate auf >=secondary glaube ich mittlerweile auch, dass man diesen Krieg nicht gewinnen kann, ujnd ich die Routing-Regel anpassen muss. Noch sind diese Dinger aber in der Liste.

Also, wer will noch mal, wer hat nich nicht? Mit paar Mitmachern ist die Liste bald leer.

PT-53 wrote:

wollte diese als "falsche Fehler" melden. Das funktionierte aber nicht.

Wie beschrieben ist da eine Abfrage drin, ob vor "mark as false positive" mindestens 5 Routing Requests in der Gegend gemacht wurden. War es das?

Danke an alle Mitkämpfer

Offline

#9 2017-10-12 10:35:43

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

abrensch wrote:

Das auf einem extrakt zu rechnen hat den Nachteil, dass dabei zusätzlich offene Enden entstehen an der Grenze des extrakt-polygons. Die liegen aber alle im Ausland.

Also in der folgenden Liste die ausländischen suspects nicht weiter betrachten:

o.k. geht besser, jetzt mit der administrativen Grenze für Deutschland gefiltert.

http://brouter.de:443/brouter/suspects


Und auch nurnoch 300 suspects übrig...

Offline

#10 2017-10-12 10:47:16

Nakaner
Member
Registered: 2011-09-03
Posts: 1,763
Website

Re: QS Fernwegenetz

Hallo,

Zwei kleine, einfach zu implementierende Usability-Verbesserungsvorschläge hätte ich noch:

1. Bei den Links zu osm.org kannst du auch einen Marker setzen, hier ein Beispiel: http://www.openstreetmap.org/?mlat=49.8 … 9&layers=N

2. Du könntest einen Link ergänzen, der die Stelle im JOSM (über Remote-Control) öffnet. Das wäre dann z.B. http://osmose.openstreetmap.fr/de/josm_ … y111295201
Den Parameter select kannst du weglassen, wenn du keine Node-ID zur Verfügung hast.

Viele Grüße

Michael


Bitte aussagekräftige Threadtitel verwenden und bei Änderungssätzen einen aussagekräftigen Kommentar eingeben.

Offline

#11 2017-10-12 11:34:13

Schienennagelhammerträger
Member
Registered: 2017-03-03
Posts: 15

Re: QS Fernwegenetz

abrensch wrote:

Also, wer will noch mal, wer hat nich nicht? Mit paar Mitmachern ist die Liste bald leer.

Soll man die nach Korrektur confirmen? Ging da irgendwie nicht ... Da habe ich bissele gesucht, bis ich die Ursache fand in einer restriction: no statt only bei straight_on ...

Das sieht nach Unfall bei Inspector-Korrektur aus, aber das sollte sich ein chroniklesegewandterer anschauen, was da hingehört ...

Offline

#12 2017-10-12 12:21:41

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

Schienennagelhammerträger wrote:

Soll man die nach Korrektur confirmen? Ging da irgendwie nicht ...

ja bitte.   "mark as confirmed" und dann "mark as fixed"

fuer "mark as a confirmed issue" fordert er nur einen Routing-Request in der Gegend, aber ganz ohne da Routing-Versuche gemacht zu haben, kommt eine Fehlermeldung.

Das soll ein Spamschutz sein, oder auch ein Schutz vor Such-Index-Robotern, die ja theoreitsch bei so einer einfachen HTML-ANwendung alle suspects verschwinden lassen können...

Offline

#13 2017-10-12 15:48:39

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

Nakaner wrote:

1. Bei den Links zu osm.org kannst du auch einen Marker setzen, hier ein Beispiel: http://www.openstreetmap.org/?mlat=49.8 … 9&layers=N

2. Du könntest einen Link ergänzen, der die Stelle im JOSM (über Remote-Control) öffnet. Das wäre dann z.B. http://osmose.openstreetmap.fr/de/josm_ … y111295201

Erledigt ( siehe http://brouter.de:443/brouter/suspects )

Mit JOSM hast Du mich fast erwischt, hab' JOSM bisher nicht verwendet, aber ich hab's hingekriegt und es funktioniert tatsächlich mit remote control. Hab versucht, den Zoom ähnlich einzustellen wie in dem BRouter-Web view.

Danke für die Tipps,

Gruss, Arndt

Offline

#14 2017-10-12 20:46:59

hsimpson
Member
Registered: 2015-07-21
Posts: 284

Re: QS Fernwegenetz

PT-53 wrote:

Hallo,

ich habe mir die "Fehler" in meiner direkten Umgebung angeschaut und wollte diese als "falsche Fehler" melden. Das funktionierte aber nicht.
Es handelt sich um folgende Straßen / 'Stellen:
1.) http://brouter.de/brouter-web/#zoom=16& … le=car-eco
2a.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco
2b.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco

Bei beiden Straßen handelt es sich um Sperrungen wegen Baustellen / Neubau.
Den Stummel der alten B 311 (1.)) habe ich heute noch auf vehicle=destination bzw. vehicle=no gesetzt.

Grüße aus Oberschwaben
Peter

Hi Peter!

Deine 1) ist definitiv ein Fehler!
Wie ich die Situation deute ist die alte B311 einer Umgehung gewichen. Damit vierliert sie aber auch die Eigenschaft als highway=primary! Und das ref=B 311 dürfte auch nicht mehr korrekt sein. Wenn du diese beiden Punkte korrigierst, wird der Fehler auch aus der Liste verschwinden.

Zur 2) hätte ich die Frage, wie lange diese Baustelle existiert, und wer sich um die aktualität der Daten in dem Bereich kümmert!

Viele Grüße,

hsimpson

Offline

#15 2017-10-13 08:38:04

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 502

Re: QS Fernwegenetz

hsimpson wrote:
PT-53 wrote:

Hallo,

ich habe mir die "Fehler" in meiner direkten Umgebung angeschaut und wollte diese als "falsche Fehler" melden. Das funktionierte aber nicht.
Es handelt sich um folgende Straßen / 'Stellen:
1.) http://brouter.de/brouter-web/#zoom=16& … le=car-eco
2a.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco
2b.) http://brouter.de/brouter-web/#zoom=15& … le=car-eco

Bei beiden Straßen handelt es sich um Sperrungen wegen Baustellen / Neubau.
Den Stummel der alten B 311 (1.)) habe ich heute noch auf vehicle=destination bzw. vehicle=no gesetzt.

Grüße aus Oberschwaben
Peter

Hi Peter!

Deine 1) ist definitiv ein Fehler!
Wie ich die Situation deute ist die alte B311 einer Umgehung gewichen. Damit vierliert sie aber auch die Eigenschaft als highway=primary! Und das ref=B 311 dürfte auch nicht mehr korrekt sein. Wenn du diese beiden Punkte korrigierst, wird der Fehler auch aus der Liste verschwinden.

Zur 2) hätte ich die Frage, wie lange diese Baustelle existiert, und wer sich um die aktualität der Daten in dem Bereich kümmert!

Viele Grüße,

hsimpson

Zu 1.) Die Ortsumgehung von Unlingen (neue B 311) ist seit einigen Wochen auf einer Teilstrecke in Betrieb. Der Rest soll Mitte kommender Woche fertiggestellt und freigegeben werden. Dann wird auch die alte B 311 auf 3,5 m verschmälert und als Feldweg dienen. Ich werde mir das mal in den nächsten Tagen vor Ort ansehen und danach OSM aktualisieren.
Zu 2.) Die L 280 ist (fast) fertig und soll am kommenden Montag für den Verkehr freigegeben werden. Das schaue ich mit vorraussichtlich am Sonntag mal an.

Grüße aus Oberschwaben
Peter

Offline

#16 2017-10-13 09:19:48

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 7,777

Re: QS Fernwegenetz

abrensch wrote:

ja bitte.   "mark as confirmed" und dann "mark as fixed"

Geht nicht.
marking confirmed requires at least 2 recent nearby waypoints from BRouter-Web, found: 0


Mapper aus dem Münsterland / NRW.

Offline

#17 2017-10-13 09:46:24

Protoxenus
Member
From: Ostseeküste
Registered: 2008-10-26
Posts: 64

Re: QS Fernwegenetz

chris66 wrote:
abrensch wrote:

ja bitte.   "mark as confirmed" und dann "mark as fixed"

Geht nicht.
marking confirmed requires at least 2 recent nearby waypoints from BRouter-Web, found: 0

Bei mir gleicher Fehler.

Offline

#18 2017-10-15 12:01:13

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

Die Liste ist jetzt erstmal leer (bis auf so einen TR-verkorsten Anschluss in Pirna, der mir zu schwierig ist)

Lessons learned:

BRouter macht bei den access-tags für die Autoprofile eine positive Prüfung (access ?= <leer>|yes|permissive|designated|destination )

Das ist deswegen gut, weil ein Routingfehler, der in eine Sackgasse führt als sehr viel schwerwiegender empfunden wird als einer, der einfach nur nicht den besten Weg gefunden hat (und nur darum gehts ja hier in diesem Thread)

Es ist aber auch schwierig, von access=Kraftverkehr, allowed, yes|no|yes, request, etc war alles dabei.

Speziell die falschen lane-taggings (access=yes|no|yes) sind von der Menge her ein echtes Problem.

Die impliziten Sperren speziell bei barrier=lift_gate|cycle_barrier auch.

Ansonsten waren es (nach meiner Fehler-Korrektur in BRouter) nur relativ wenig TR-Fehler.

Relativ viele unvollständig zurueckgebaute Sperren. Irgendwo ein Ministueck wird da übersehen. Ich hab den Eindruck gewonnen, dass die visuelle Prüfung von temporären Sperren ziemlich gut funktioniert. Also wenn da eine Baustelle auf der Karte klar ersichtlich ist, dann ist die auch fast immer richtig. Wenn aber jemand eine Baustelle irgendwo nur funktional abgebildet hat, durch einen Sperrknoten oder eine unsichtbare Wegsperre (z.B. vehicle=no), dann setzt die schnell mal Staub an.

3 Fälle hatte ich, wo Landesstrassen nur für Land- oder Forstwirtschaft freigegeben sind,

In einem Fall war das aus Medienberichten als Sperre wegen Strassenzustand ersichtlich. In zwei Fällen habe ich das korrigiert: Beim Flugplatz Finow und bei der L2055 von Ascherode nach Wulfingerode. Bei letzterem gab's Protest und Revert. Das Sperr-Schild in Ascherode ist in Mappilary zu sehen, in den Esri-Bildern aber auch mehrere Kfz auf dem angeblichen Feldweg. Und die Kollegen bei Guugel interessieren sich auch nicht für die Sperre. Würde ja gerne mal vorbeifahren um das zu verstehen...

Der Scanner läuft jetzt cron-gesteuert immer Sonntag morgens auf dem Geofabrik-Gemrnay-Extrakt, der eine erstaunlich kurze Latenz zu haben scheint. So kann man relativ zeitnah noch Korrekturen machen, bevor am Montag Morgen der Snapshot für den Planet-Dump gemacht wird (der dann Donnerstags bei BRouter ankommt).

PS: @geofabrik: ihr habt bestimmt auch einen Planet-Dump mit kürzerer Latenz und weniger Störungen als den offiziellen :-)

Offline

#19 2017-10-15 21:26:43

abrensch
Member
Registered: 2013-01-07
Posts: 317

Re: QS Fernwegenetz

abrensch wrote:

Ansonsten waren es (nach meiner Fehler-Korrektur in BRouter) nur relativ wenig TR-Fehler.

was aber wohl nur heisst, dass dieses Sieb dafür nicht geeignet ist.

Hab' einen anderen Test gebaut, der nach TR-Fehlern fischen soll. Was er tatsächlich macht ist, die TRs zu suchen, die tatsächlich eine Wirkung haben. Dass sind natürlich die guten. Aber keine Wirkung ohne Nebenwirkung, also vermutet man in dieser Liste eben auch die Fehler.

Allerdings muss man viele Kreuzungen testen, um einen Fehler zu finden, die false-positive-Rate ist also ziemlich hoch (>95%)

Was man aber dann findet ist sowas hier (die hab ich aber alle schon bearbeitet!):

http://brouter.de/brouter-web/#zoom=18& … le=car-eco

http://brouter.de/brouter-web/#zoom=16& … le=car-eco

http://brouter.de/brouter-web/#zoom=17& … le=car-eco

http://brouter.de/brouter-web/#zoom=16& … le=car-eco

http://brouter.de/brouter-web/#zoom=17& … le=car-eco

Nicht immer ist die angezeigte TR dann auch der Fehler. Gibt da auch komplexere Wechselwirkungen.

hab diese Liste der TR-Kanditaten jetzt einfach mal in die "suspect" Liste eingespeist, auch wenn der Name "suapect" hier eigentlich nicht passt. Sollte eher heissen: "wirksame TR, die es sich lohnt zu testen"

Offline

Board footer

Powered by FluxBB