Siehe auch hier:
Bei einer Messfahrt vorgestern wurden in einer Straße, die links und rechts aus einer Autospur und in der Mitte aus zwei auch vom Bus genutzten Straßenbahntrassen besteht, ein Teil der Messwerte der Straßenbahntrsse zugeordnet (vgl. beigefügten Screenshot und der zugehörige Kartenausschnitt). Ist es möglich, dass in der OSM-Karte ein Paramter für die Straßenbahntrasse fehlt oder falsch gesetzt ist, so dass Messwerte des obs auch der Straßenbahntrasse zugeordnet werden? Werden die falsch der Straßenbahntrasse zugeordneten Messwerte nach Anpassung der OSM-Kartenparameter im Portal richtig der Fahrspur zugeordnet? Oder muss ich mal wieder manuel eingreifen und die Korodinaten der falsch der Straßenbantrasse zugeordneten Messpunkte „richtigstellen“?
@mfgutmann Wenn die Parameter in der OpenStreetmap richtig sind, und der Admin die Kartendaten im Portal aktualisiert und eine Neuberechnung der Events anstößt, sollten die Events (und Tracks) von allein aufhören, auf der Straßenbahn zu landen.
An der Ecke sieht es so aus, als sei die Straßenbahn als „highway:service“ getagged - manchmal auch mit „access:no“ aber ich bin nicht sicher, ob wir das auswerten. Die Straßenbahn hat auch an anderen Stellen kein „highway:service“, obwohl sie dort auch „surface:asphalt“ hat, von daher würde ich tippen, dass „highway:service“ evtl ein falscher tag ist.
Wir hatten das Problem in Darmstadt in der Bismarckstraße auch schon mal und haben es über tagreparatur + Mapimport behoben.
In welchem Portal hast du denn das Problem?
Weil es hier um eine Auswertung unter Zeitdruck geht noch der Hinweis: Die Messwerte sind immer nur so gut wie die OpenBikeSensoren und die Aufklärung der Nutzer- Sprich: hat man die Wartung selbst gemacht und z.B. beim Verleih bei der Montage geholfen? Weiß man, welche Drückregeln für Überholvorgänge die Menschen im Kreis nutzen? Dann weiß man, wie gut die Daten lokal sind. Fahren hingegen Unbekannte mit von Unbekannten selbst gebauten und montierten Sensoren in einem Landkreis herum, ist es insbesondere bei krassen Ergebnissen wichtig, die Messwerte selbst kritisch zu hinterfragen. Das tun sonst leider im Nachgang die weniger Fahrradfreundlichen Leute.
Es gab mal einen Fall in dem in einem Kreis Sensoren verwendet wurden, deren Ultraschallsensoren rauschten, so dass reproduzierbar Zufallsmesswerte, aber meist unter 150 Zentimeter herauskamen. Sowas sollte man ausschließen, bevor man mit den Messwerten an die Öffentlichkeit geht, oder zumindest ehrlich sagen, wie viel man über die Nutzer und den Gerätezustand weiß. Das ist auch einer der Gründe, warum wir uns entschieden haben, im Portal nicht Abstandsstatistiken „Nach Region/Landkreis“ anzubieten - die Datenlage deutschlandweit ist zu heterogen, um Aussagen zum Vergleich von Kreisen zu treffen…
Klaus erwähnte auch bereits: Ebenso ist die Lokale Qualität der Zuordnung innerorts/außerorts anhand der Openstreetmap stark unterschiedlich. (Ob das Auswirkungen hat, kann man aber mit vertretbarem Aufwand prüfen, indem man die „Zone“ Ansicht im Portal wählt. und über die Karte scrollt, wenn es keine Straßen mit vielen Events in der falschen Farbe gibt, hat man kein Problem.
@gluap Danke für die schnelle Rückmeldung. Ich werde mit einem Kollegen aus dem ADFC die Parameter für diese Straßenbahnlinie prüfen und ggf. ändern und dann wegen des Kartenimports Bescheid geben. Wir vom ADFC Mainz-Bingen arbeiten mit dem „Standardportal“ https://portal.openbikesensor.org/, da wir nicht das Know How und die Kapazitäten haben, ein eigenes Portal für RLP einzurichten und zu betreiben - zumal ich den Föderalismus in diesem Punkt auch nicht für sinnvoll erachte, da ich z.B. regelmäßig auch auf der hessischen Seite unterwegs bin (dort aber bisher ohne Sensor).
Für den ADFC Mainz-Bingen bin ich der Korodinator und Ausleiher unserer 5 obs. In Bingen unterstütze ich gerade ein Projekt des Fahrradbeauftragten und des VCD, um auf der Grundlage von Messfahrten wenigstens mal Basics auf die Fahrbahn zu bringen (Aufstellflächen, Piktogramme, rote Furten etc.). In Mainz ist die Bereitschaft für Messfahrten leider noch nicht so groß.
Wenn ich verleihe, dann habe ich 2 Verleihmodi: Entweder der Entleiher ist technisch kompetent, um die Einrichtung des obs und die Auswertung im Portal selbst durchführen zu können - dann weise ich darauf hin, dass zweifelhafte Messwerte gelöscht und einer Straße falsch zugeordnete Messwerte korrigiert oder ebenfalls gelöscht werden sollen bzw. biete meine Hilfe dafür an. Das hat in Bingen - soweit ich das überblicken kann - sehr gut funktioniert. Bei weniger technisch kompetenten Entleihern lade ich die Daten über einen ADFC-Account in das Portal und schaue mir die Daten dann wegen evtl. Korrekturen an.
Leider gibt es in Mainz schon Einträge von mir unbekannten Personen, bevor wir vom Kreisverband Mainz-Bingen mit dem Projekt unserer 5 Sensoren gestartet sind. Da erscheint mir Manches nicht plausibel, aber an die Daten komme ich natürlich nicht dran.
Hups, eigentlich hatte ich meinen Kommentar für die Datenqualität in einen anderen Thread schreiben wollen. Aber dadurch dass ich unterwegs den Rechner gewechselt habe und auch hier noch den Kommentar offen hatte hab ich es versehtnlich hier abgeschickt.
Klingt aber als würde es bei euch gut laufen 
Die Karten im Hauptportal kann ich importieren.
In den OSM-Karten ist access=no für die mittige Straßenbahnlinie eingetragen. Unter „erlaubter Zugang“ steht Fahrräder=no. Warum werden trotzdem Messpunkte der mittigen Straßenbahnlinie zugeordnet?
Es geht um die noch nicht öffentliche Fahrt 2024 01 23T15 09 12 b095 im allgemeinen Portal.
Danke für eure Untersuchung, das hilft deutlich weiter. In der Vergangenheit hatten wir das Problem schonmal, damals war es aber so, dass wir den schienentyp radbefahrbar gesehen haben. Hier ist „highway=service, access=no, bicycles=no“, wie du schreibst. Ich hab die entsprechenden Ausschlüsse dem Übersetzungsscript hinzugefügt und kann demnächst eine Neuaswertung der Tracks mit den neuen Kartendaten anstoßen. (ETA Wochenende)
Bin da technisch nicht involviert, habe das Problme selbst nicht und muss es auch nicht umsetzen, aber so rein aus Interesse: Müssten die Anpassung im Code alle Portal-Betreibenden eigenständig übernehmen, oder greifen die Portale beim Anstoßen einer Neuauswertung automatisch online darauf zu?
EDIT: Danke, das hat sich erledigt 
Messpunkte separieren in Innerorts- und Außerorts-Überholungen - #6 von gluap
Hallo zusammen! Ich bin der Mainzer Mitstreiter von Michael und bin auch recht aktiv bei OpenStreetMap.
Danke für deine Anpassung des Skripts! Ich habe gerade noch eine Anmerkung zu deinem Git-Commit hinzugefügt, damit auch alle Fälle abgedeckt werden.
LG
Fabian
1 „Gefällt mir“
Hallo zusammen,
wann wird im allgemeinen Portal die neue Version installiert, die die fehlerhafte Zuordnung von Messpunkten bei Straßen mit Straßenbahnschienen beseitigt? (vgl. mein Post vom 25.1. mit nachfolgender Kommunikation). Ich würde gerne meine Messreihe veröffentlichen.
Vielen Dank im voraus für das Update.
Michael
Noch eine Frage zu diesem Thema:
Im Portal sind viele Messwerte einem parallelen Schienenweg bereits zugeordnet (vgl. Screenshot aus Mainz). Können diese nachträglich noch dem Straßenzug Kaiser-Karl-Ring zugeordnet werden - passiert das evtl. automatisch, wenn die OSM-Parameter richtig gesetzt sind? Auch in diesem Fall handelt es sich um eine abgesetzte Straßenbahntrasse, die aber von Kfz zur Überholung oder von Bussen genutzt werden kann. In Gegenrichtung ist die Zuordnung richtig erfolgt.
Entschuldige bitte - das ist im Stress Anfang Februar untergegangen. Vorbereitung für den Import läuft jetzt.
Was stand heute Abend schon in der OpenStreetMap richtig war (bicycle=no oder vergleichbar), sollte dann auch richtig zugeordnet werden, wenn die Werte neu berechnet werden. Beim Neuberechnen werden die Werte den Straßensegmenten neu zugeordnet, so wie die OpenStreetMap es zu diesem Zeitpunkt dann hergibt.
Bei zwei parallel verlaufenden Wegen, die beide von Fahrrädern befahrbar sind, gibts derzeit keine möglichkeit, die Zuordnung manuell vorzunehmen.
Die Karte ist jetzt fertig importiert. Wenn ich deine zwei Beispiele richtig zugeordnet habe, wird dort jetzt nicht mehr versehentlich auf Straßenbahnschienen zugeordnet.
Vielen Dank !!! Die Zuordnung ist jetzt richtig.
Wenn man mt dem obs bzw. dem Portal arbeitet, kommen leider auch immer wieder neue Fragen…
- Was können wir machen, wenn wir in unserer Region (Mainz/Bingen) Messpunkte finden, die falsch sind und wir den Verursacher nicht kennen. Dem Datenpunkt ist kein Nutzername und keine Identifikation der Fahrt zugeordnet. Könnt ihr als Administratoren den Namen der Fahrt mit dem falschen Datenpunkt und eine E-Mail-Adresse zur Verfügung stellen, so dass wir den Datenlieferanten um Korrektur seiner Messdaten bitten können? Oder könnt ihr/wir als ultima ratio auch einen definitiv falschen (bzw. einer falschen Straße zugeordneten) Messwert löschen? Gegenüber einer Stadtverwaltung ist es wichtig, dass der Datenbestand bereinigt ist, da ansonsten die Auswertungen nicht als glaubwürdig angesehen werden.
- private Fahrten sind in der Karte sichtbar. Ist das so gewollt? Ich verstehe das Konzept so, dass private Fahrten noch korrigiert werden müssen, bevor sie veröffentlicht werden. Oder jemand möchte aus irgendwelchen Gründen eine Fahrt privat lassen.
- bei den veröffentlichten Fahrten wird über eine Auswahl in der Lasche Fahrtetn der komplette Fahrtverlaf angezeigt. Dies stößt bei meinen Nutzern auf Bedenken. Da oft auch Messwerte nahe dem Wohnort aufgezeichnet werden sollen, sollte der Fahrtverlauf (rote Linie in der Karte) nach Veröffentlichung nicht mehr angezeigt werden.
Nachtrag zu Frage 1: Beigefügter Screenshot zeigt zwei Datenpunkte mitten im Fluss und 2 Datenpunkte abseits in Gebäuden. Wir wisssen nicht, wo die herkommen und würden sie gern löschen.
@mfgutmann:
1.) Wenn ihr nur mit eigenen kuratierten Daten arbeiten wollt, ist derzeit der leider einzige Weg, selbst ein Portal aufzusetzen, in das nur ihr hochladet. Der ADFC Darmstadt macht das zum Beispiel so, um genauer sagen zu können, wie die lokalen Messwerte zustande gekommen sind. Oder ihr loggt euch auf dem zentralen Portal ein und filtert auf „nur meine Tracks“, wenn diese Funktion euch ausreicht.
Die Datenpunkte, die du anzeigst sind aber zumindest auf dem Screenshot nicht „falsch“, sondern sehen nach leichtem Rauschen beim GPS-Messwert aus. Die neo6m Module können bei schlechtem Wetter oder wenn die Antenne nicht die beste ist ein Stück driften. Ab einem gewissen Abstand von der Straße werden die Punkte nicht mehr auf eine Straße zugeordnet und dann auf den zugeordneten Ort gezogen, sondern genau am „GPS-Messpunkt“ angezeigt. Der Fahrer wird auf einer der beiden Straßen neben dem Fluss unterwegs gewesen sein. Es kann sein, dass sich das in zukünftigen Iterationen des Snappingalgorithmus verbessert.
Vor dem Snapping sehen die Überholmesspunkte ungefähr so aus:
Da erkennt man das Rauschen leichter.
Hier sieht man einige von meinen Fahrten bei denen man gut sehen kann wie das GPS einmal ausgerissen ist - in diesem Fall vermutlich wegen einem hohen Gebäude mit Metallverkleidung, das bei dieser Fahrt Satelitensignale zurück geworfen hat:
Allgemein geht es bei der Auswertung der Daten um Statistik, und ein einzelner Messpunkt trifft kaum eine Aussage - Interessant ist es nur, wenn man eine gewisse Mindestmenge an Messwerten auf einer Strecke gesammelt hat, und die paar Punkte Schönheitsfehler außen herum fallen dann nicht mehr ins Gewicht.
2.) Die aggregierten Daten (Überholvorgänge, kumulierte road usage) sind immer in der Karte sichtbar. Das Konzept ist, dass man in Ausnahmefällen mal einen genauen Track mit jemandem diskutiert - und den dann öffentlich schaltet damit andere genau diese Fahrt unter „Fahrten“ anschauen können. Eben weil man ihm die rote Linie zeigen will. Öffentlich schalten sollte man Tracks aber nur in solchen Ausnahmefällen. Der Infotext am Haken gibt dazu den Hinweis, dass die Messwerte auch ohne „öffentlich schalten“ sichtbar sind:
Es gibt keinen Mechanismus, um Daten manuell zu korrigieren. Es wird davon ausgegangen, dass genug Daten gesammelt werden, dass Ausreißer in der Statistik untergehen.
3.) Siehe 2., man sollte keine Fahrten veröffentlichen, wenn das Ziel nicht ist, den kompletten Fahrtverlauf öffentlich anzuzeigen.
Danke für die ausführliche Antwort.
Der Hinweis auf die FIlterung „nur meine Tracks“ hilft etwas. Da ich eine allgemeine ADFC-Kennung für Mainz eingerichtet habe, kann ich unter dieser Kennung die geprüften Tracks speichern und auswerten, sofern mir alle teilnehmenden Mitglieder die Daten zum Hochladen anvertrauen.
Für ein eigenes Portal haben wir weder die Kenntnisse noch die Möglichkeiten.
Ich dachte bisher, dass in der Karte nach dem Snapping nur bestätigte Überholvorgänge angezeigt werden. Scheinbar werden aber auch Messpunkte angezeigt, die nach dem Hochladen des Tracks in der Karte nicht als bestätigter Überholvorgang sichtbar sind. Wenn ich diese Ausschläge nach dem Hochladen als Überholpunkte sehen würde, würde ich sie eliminieren. Ein Beispiel habe ich beigefügt: Im markierten Trapez bin ich nie gefahren und den Überholpunkt finde ich bei der Anzeige meiner Tracks nicht. In der Grafik rechts findet sich auch keine Messwert. Wie kann ich diese Ausreißer identifizieren, um sie löschen zu können?
Ich kann den Punkt und die Befahrung des Trapezes in der Datenbank nicht sehen - Könnte es sein, dass dein Browser hier noch Kartendaten gecached hat?
Hier der Bereich und die Datenbankabfrage auf portal.openbikesensor.org.
Die Kartendaten, die Serverseitig relativ teuer zu berechnen sind werden 24 Stunden gecached. Evtl. hast du (oder jemand anderes) den entsprechenden Track in der Zwischenzeit gelöscht?
Im Markierten Bereich ist in der Datenbank kein Überholpunkt zu finden.
Danke für die Mühe. In der Tat ist heute der Datenpunkt weg. Nun weiß ich, dass ich nach der Bereinigung der Daten etwas warten muss, bis wirklich alles umgesetzt ist.
1 „Gefällt mir“