Auto-Route führt durch Bollard

Das ist ja übel.
Ist aber ohne Ortskenntnis in der Tat heikel zu reparieren…

Wäre es ne Möglichkeit Keepright aufzurüsten?

  1. Barrier auf einer Kreuzung, dürfte meistens falsch sein (wie oben).
  2. Barrier als einzelner Punkt ohne Verbindung zu einem highway (kann kaum ausgewertet werden).

Die Analyse sieht bei mir so aus:

Alle bollards ermitteln, an denen mehr als 1 way dran hängt, wobei mindestens 2 dieser Ways mit highway={residential, living_street, primary, secondary, tertiary, unclassified} getaggt sein müssen und mindestens 2 verschiedene name=* vorkommen. Entsprechende GPX-Datei barrier3a.gpx

Alle bollards ermitteln, an denen wieder mehr als 1 way dran hängt und mindestens einer dieser Ways mit highway={residential, living_street, primary, secondary, tertiary, unclassified} getaggt wurde und dort der Bollard nicht am Anfang/Ende vorkommt. Entsprechende GPX-Datei barrier3b.gpx

“Herumfliegende” bollards lassen sich recht einfach ermitteln (SQL). Da muss man nur schauen, ob die Bollard Knoten-Id in einem Way vorkommt. Liefert leider eine Unmenge an false positives wg. Deko.

Gleiches gilt auch für die anderen barriers, also cycle_barrier, gate, wall. Die baue ich gerade noch ein, ebenso weitere highway=*. Erledigt.
Edit: Links zu den beiden GPX-Dateien siehe oben, Split der 1893 barrier in kleinere Teile folgt noch.

Barrier-Fehlersuch-Aktion

Die Arbeitspakete für insgesamt 1893 potentielle barrier-Probleme sind jetzt geschnürt mit jeweils 50 Problemen pro Arbeitspaket.

In der Zip-Datei findet ihr:

  • Verzeichnis auswertung_1: 15 Arbeitspakete für Auswertung 1 (siehe Beschreibung im vorherigen Post)

  • Verzeichnis auswertung_2: 23 Arbeitspakete für Auswertung 2 (siehe Beschreibung im vorherigen Post)

  • In jedem Verzeichnis nochmal 1 GPX mit allen Fehlermeldungen in einer Datei (für den besseren Überblick)

Ebenfalls enthalten darin das SQL-Statement, falls jemand das ganze detailliert nachvollziehen möchte.

Vielleicht kann jemand mal einen groben Blick drüber werfen, ob die Zahl der false positives nicht zu hoch ist.
Als nächstes dann die Wiki-Seite: gibt es da gute Vorlagen?

Auch immer willkommen sind Ideen, die Auswertung zu verbessern!

Gruß,
mmd

Jetzt gibt es eine Wiki-Seite für das Barrier-Problem im Stil der bisherigen Aktionen. http://wiki.openstreetmap.org/wiki/User:Mmd/BarrierAktion

Gruß,
mmd

Hallo mmd, danke für die Auswertungen. Ich hatte mir gestern Nr. 1 in einigen mir bekannten Gegenden angeguckt. Da wo genau 2 Highways mit den definierten Kriterien zusammenstießen, waren es allesamt false positives, so dass ich für diese Auswertung eher folgendes vorschlagen würde:

Alle bollards ermitteln, an denen mehr als 2 ways dran hängen, wobei mindestens 2 dieser Ways mit highway={residential, living_street, primary, secondary, tertiary, unclassified} getaggt sein müssen

Die Anforderung mit den unterschiedlichen Namen würde ich eher weglassen, oder soll die eine ganz bestimmte Art false positives verhindern?

Hallo,
ich hab gestern Nr.3 gemacht.
Vorschlag für neue Kriterien:

  • mind. einer von Klasse1 & genau einer von Klasse2, wobei der Node von Klasse2 nicht am Ende/Anfang des Weges liegt.
  • mind. einer von Klasse1 & mind. zwei von Klasse2.
    Klasse1={path, footway, cycleway, bridleway, track}
    Klasse2={residential, living_street, motorway, motorway_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, service, unclassified}

Die unterschiedlichen Namen würd ich auch eher weglassen.

Hallo g0ldfish, MasiMaster,

erstmal danke für das Ausprobieren der Listen und die Verbesserungsvorschläge! Offenbar wirft die Analyse doch noch viel zu viele false positives aus, d.h. hier ist noch Nachbessern angesagt.

Im nächsten Schritt versuche ich erst einmal eine neue Bewertungsfunktion für die Ways einzubauen, damit das Zählen unabhängig davon funktioniert, ob der bollard am Anfang/Ende oder irgendwo mittendrin liegt.

Situation 1: ------Way 1----(bollard)-----Way 2
Situation 2: ------Way 1----(bollard)-----Way 1

Situation 1: Bollard jeweils am Ende von Way 1 und Way 2. Beide Ways werden jeweils mit 1 bewertet, d.h. beide Ways haben nur einen “Arm”.
Situation 2: Bollard mittendrin in Way 1. Dieser Way wird dann mit 2 bewertet, da er vom bollard aus gesehen 2 Arme hat.

Das sollte eine gewisse Normierung schaffen. Damit können jetzt die Bedingungen so formuliert werden, dass sie sich auf eine bestimmte Anzahl an “Armen” mit einem bestimmten highway=* Tag beziehen. Mit wievielen verschiedenen Ways das ganze gemappt ist, spielt dafür ja eigentlich keine Rolle.

Mal sehen, wie sich die verschiedenen Vorschläge hier sinnvoll kombinieren lassen. Gerne würde ich die folgende Situation noch erkennen http://www.openstreetmap.org/?node=294108878.

Die Sache mit dem Check auf “name” übrigens war so ein workaround, um noch mehr false positives auszuschließen.

Gruß,
mmd

Hallo,

es gibt jetzt eine neue Version der Auswertung zunächst als GPX für ganz Deutschland: https://docs.google.com/open?id=0Bwofz5RyfxEiQmZqalV0ejJlaW8

Die beiden Dateien haben jeweils nur 1173 bzw. 1784 Punkte drin und lassen sich auch noch problemlos in JOSM für einen ersten Blick öffnen.

barrier_masimaster_gesamt.gpx ist recht nahe an die Idee von masimaster angelehnt, allerdings habe ich noch trunk, trunk_link und service in Klasse 2 aufgenommen. Weiterhin basiert die Auswertung auf der Zahl der Arme (oder besser Äste?) an einem bollard/barrier, wie im vorherigen Post beschrieben.
Bedingung für diese Auswertung ist: an einem barrier müssen mindestens 3 Äste dran sein, wovon mindestens 2 Äste vom Typ {residential, living_street, motorway, motorway_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, service, unclassified, trunk, trunk_link, service} dran hängen, sowie mindestens 1 Ast vom Typ {path, footway, cycleway, bridleway, track}.

Die andere Datei barrier_d_gesamt.gpx arbeitet ohne die Einschränkung auf “mindestens 1 Ast vom Typ {path, footway, cycleway, bridleway, track}”.

Ist die Zahl der false positives jetzt besser geworden? Wenn nicht: bitte Knoten-Id oder Koordinaten posten für eine weitere Analyse.
Wenn der eine oder andere Fehler gemeldet wird, aber der barrier in der aktuellen Karte nicht zu finden ist, könnte das auch an meiner lokalen DB liegen, die etwa 4 Wochen alt ist. Das sollte aber eher selten der Fall sein. Update der DB erfolgt demnächst mal wieder über Nacht.

Gruß,
mmd

Übrigens: Passende SQL Statements wie immer im Zip enthalten.

Edit: Beschreibung oben korrigiert, es fehlt in der Bedingung für die Auswertung: “mindestens 3 Äste an einem barrier”

Hallo,

eine erste Tranche mit besonders gravierenden Fehlern habe ich jetzt in Changeset #12134076 gefixt. Dabei wurden nur mind. 2 Äste mit highway=primary*, secondary*, tertiary*, trunk*, motorway* berücksichtigt. False positives waren in dieser Auswahl <10%.

Hat sich jemand schon die anderen barrier aus dem letzten Post ansehen können und kann Feedback zur Qualität der Daten geben?
Ich würde gerne die Wiki-Seite aktualisieren, das geht aber nur, wenn die Daten einigermaßen brauchbar sind.

Gruß,
mmd

.

Hallo mmd,

ich hatte mir letzte Woche einiges in Norddeutschland angeguckt, fand aber fast alles zu uneindeutig, um es ohne Vor-Ort-Sichtung zu korrigieren. Einzig in einem Dorf waren gehäuft Kanditaten für eine Korrektur, da habe ich einen lokalen Mapper angeschrieben (wurde umgehend geändert). Wie siehst denn mit den Bollards ohne Highway aus? Vielleicht käme man da über eine räumliche Abfrage weiter, um die “dekorativen” Poller auszufiltern, die sind ja meistens linear oder sonstwie in Gruppen).

Gruß,
g0ldfish

Hallo g0ldfish,

das ist ja prima, dass immerhin ein paar Bugs gefixt werden konnten. Vielleicht kannst Du dir den aktuellen Stand nochmal ansehen, die Files wurden am Wochenende nochmal komplett neu mit anderen Regeln (die von masimaster) aufgebaut. Erstmal ist die Zahl der Bugs kleiner geworden und hoffentlich auch die Zahl der false positives geringer.

Per Skript die barrier zu prüfen ist recht aufwändig, da könnte ein Tor zu einem Friedhof sein → häufig gehört der nicht auf die Straße. Oder, auf der Straße führt schon eine Buslinie - auch dort macht ein barrier eher wenig Sinn. Das kommt alles sehr auf den Einzelfall an, daher wäre es schon hilfreich, wenn sich ein paar Mapper die Dateien mal ansehen könnten und dann entscheiden -
a) ganz sicher ein false positive → nichts machen
b) könnte ein Bug sein, aber nicht klar: OpenStreetBug erfassen oder lokalen Mapper kontaktieren…
c) ganz sicher ein Bug: nochmal drüber nachdenken und dann korrigieren

Das ganze ist schon etwas zeitaufwändig, daher habe ich mich entschlossen, eine Aktion aufzusetzen, damit sich man sich die Arbeit etwas aufteilen kann.

Zu den “losen” barriers: erstmal sind die zahlenmässig noch häufiger und dort false positives (“Deko”) herausfiltern, dürfte recht aufwändig sein. Irgendwo hatte ich mir diese Punkte schonmal ermittelt, da muss ich nochmal nachschauen. Wenn würde ich aber eher als ein GPX hier zur Verfügung stellen und nicht weiter in Pakete herunterbrechen (je nach Bedarf).

Gruß,
mmd

nochmal allgmein zu barriers:
wie die access-Werte angeben?
zB bollard:

  1. access=foot;bicycle

  2. foot=yes + bicycle=yes

  3. wie 2) + motor_vehicle=no

?

  1. kannste gleich wieder vergessen.

  2. oder 3) kommt halt drauf an…

Wenn man nur wenige erlauben möchte, ist ein access=no + {wenige}=yes sinnvoll. Willst du wenige sperren, dann {wenige}=no. Bei manchen Objekten kann das access=no schon default sein, ich finde es aber schon sinnvoll, das nochmal explizit zu taggen, damit für alle klar ist, was man meint.

Die Poller halten doch eher 2-spurige Fahrzeuge auf, dann passt motorcar=no wohl besser :slight_smile:

Stimmt. my fault.

Bei genauem access-tagging erkennt man ähnlich wie bei genauem Schilder-mapping den Schwachsinn, der in der Landschaft rumsteht.

Vor meiner Haustür stehen im beschilderten Radweg cycle-barriers rum.
Mit standard-access-Werten kann nur schrott-routing rauskommen.

Allerdings ist es auch doof die dahin zu bauen nur um Radler zu bremsen um zu verhindern dass die wie irre über die kreuzende Straße schiessen… also fährt halt jeder auenrum :roll_eyes:

Mein Eindruck, wieviele der Barrieren korrigiert werden müssen. (Bei den unteren 3en hab ich nur 10-12 Stichproben genommen)
auswertung_1: etwa 10-20%
auswertung_2: etwa 80-90%
barrier_masimaster_gesamt.gpx: >95% (keinen false positives gefunden)
barrier_d_gesamt.gpx: >90% (einen vielleicht-false positives gefunden)

Anmerkung:

  1. die schmalen Spalten mit GPX-Daten über ganz Deutschland erscheinen mir gut zur Handhabung. (besser als Quadrate)
  2. 50 find ich ein wenig viel, wenn man ggf. manchmal noch ein OSBug setzen muss/will, kann das länger dauern und ggf. Leute abhalten, zumindest geht es mit so :slight_smile: zB. 30 währen genug.

Hallo,

nochmal zu den “losen” barrier, die sich g0ldfish gewünscht hatte. Die sind erwartungsgemäß recht zahlreich: Hier eine Auswertung mit insgesamt 11197 barrier. Kriterium: barrier kommt nicht im Weg vor. Distanz zu anderen Wegen, oder andere geom. Eigenschaften spielen keine Rolle.

Gruß,
mmd

Die losen Barrier sind Klasse! Bei ca. 25 die ich verbessert habe war kein Deko dabei.
Ist auch relativ einfach zu verbessern (praktisch blind), da idR klar ist, wo die Barrier eigentlich hingehört.