Bei meiner letzten Messfahrt (und gelegetlich auch schon mal vorher) wurden Messwerte einer falschen Straße zugeorndet, da die GPS-Route zu sehr von der tatsächlichen Straßenroute abgewichen ist (vgl. beigefügten Kartenausschnitt 
)
Kann ich nachträglich im Portal oder auf anderem Wege die Straßenzuordnung korrigieren? Phantastisch wäre, wenn ich den Punkt mittels Drag&Drop in der Karte der richtigen Straße zuordnen könnte.
Das Thema wird hier bereits ausführlich diskutiert:
https://forum.openbikesensor.org/t/routenglaettung-anhand-logischer-strassenfolge/128/24
Sorry, aber nach dem Lesen bin ich auch nicht viel schlauer.
Ich habe manuell in einer csv-Datei GPS-Koordinaten entsprechend Angaben in Google Maps so geändert, so dass die Überholstellen dann besser bzw. hoffentlich korrekt der Straße zugeordnet sein sollten. Nach dem Hochladen in das Portal hat sich jedoch das Bild nicht geändert - trotz Meldung Verarbeitung: complete. Ich habe nur Datensätze geändert, die in der Spalte confirmed einen postiven Wert aufweisen, nachdem ich zuvor über den Left-Abstand (der Karte entnommen) gefiltert hatte.
Warum werden die Änderungen nicht wirksam bzw. was muss ich tun, um manuell einen Überholvorgang besser/näher an die richtige Straße zu legen?
@mfgutmann Es gibt die Funktion „Bearbeitung von Messwerten“ im Portal noch nicht - es wird (link von Dennis) diskutiert solche „Sprünge über Häuser hinweg“ durch eine programmatische Plausibilitätsprüfung auszuschließen.
Siehst du denn einen entsprechenden Zacken in der ungesnappten Version deines Tracks nachdem du die modifizierte Datei hochgeladen hast? (die gestrichtelte Linie).
Leider wird mir gar nichts mehr angezeigt, obwohl ich die korrigierte csv-Datei im UTF hochgeladen habe. Ich habe die originale und die korrigierte Datei beigefügt. In den Zeilen 4025, 4032, 2719, 2715, 2713 habe ich die GPS-Daten in der Hoffnung geändert, dass nach dem Hochladen die Straßenzuordnung korrigiert ist.
Diese Stellen betreffen die Abweichungen in der Karte im Süden von Mainz an der Straße Auf der Steig. Diese bin ich nicht gefahren! Die Abstände müssten der Salvatorstraße zugeordnet sein.
Der originale Track ist unter 2022 09 29 mfgutmann Original sichtbar (OpenBikeSensor Portal), der korrigierte (leider nicht sichtbare Track) unter 2022 09 29 mfgutmann korrigiert (OpenBikeSensor Portal)
20220929 neu Neustadt Altstadtring Salvatorstr Hechtsheimer Str UTF.csv (1,5 MB)
sn1yinry.csv (1,5 MB)
Hallo @mfgutmann,
sieht so aus als sei 20220929 neu Neustadt Altstadtring Salvatorstr Hechtsheimer Str UTF.csv ein bisschen kaputt. Insbesondere die Spalten mit den Geokoordinaten (Latitude/Longitude) enthalten da Werte im Format 500.170.671 oder 82.582.779. Das sind auf jeden Fall keine Werte, mit denen die Software umgehen kann.
Vermutlich hat dein Tabellenkalkulationsprogramm (Excel?) da eine große Ganzzahl draus gemacht. Im Original steht so etwas wie 50.0179431 . Es sieht also so aus als hätte Excel den Dezimalpunkt . als Tausendertrennzeichen interpretiert und einfach weggelassen, die entstandene Zahl als „500 Millionen und ein bisschen“ interpretiert, und beim Speichern dann Punkte als Tausendertrennzeichen eingefügt.
Excel ist leider immer ein bisschen schwierig zu bändigen, wenn es um solche Details geht, die je nach Region und Sprache unterschiedlich sind. Wenn dein Excel auf Deutsch gestellt ist, erwartet es ein Komma als Dezimaltrennzeichen und eben keinen Punkt. Die CSV-Datei muss aber mit Punkt erstellt werden, und ohne Tausendertrennzeichen.
Ob der Fehler beim Import oder Export passiert (oder beides) kann ich dir nicht sagen. Vielleicht kannst du das nochmal korrigieren.
LG Paul
Hallo Paul,
vielen Dank für Deine Rückmeldung. Das hat mir schon einen großen Schritt weiter geholfen!
Ich habe die Daten mit dem Notepad eingelesen, über den Zeitstempel die Datensätze mit der „falschen“ gps-Ortung identifiziert und gemäß Google-Maps Koordinaten „justiert“.
Das hat bei vielen Messpunkten funktioniert. Allerdings ist mir das bei einem Messwert trotz vielfachen Probierens nicht gelungen. Im Screenshot 1 kann ich den Messwert 1,48, der seitlich einer falschen Straße zugeordnet ist, zwar in den Daten eindeutig identifizieren (Zeile 4025 im Screenshot 2 bzw. Zeitstempel 14:51:21 beim Einlesen in Notepad), aber nicht der richtigen Straße zuordnen - sogar wenn ich den gleichen korrigierten gps-Wert wie für den Datensatz mit dem Abstand 1,44 (Zeile 2719 bzw. 14:29:35) verwende (vgl. Screenshot 4)!
Ist es möglich, dass ich den falschen Datensatz selektiere, obwohl kein weiterer Datensatz mit 1,48 Abstand und confirmed>0 in der Datei vorhanden ist (Screenshot 2 zeigt die Selektion für Abstand 1,44 und 1,48)?
Da die Google-Maps Koordinaten ungenauer sind als die aufgezeichneten gps-Daten ist es eine ziemlich mühsame Herumprobiererei, bis der Meßwert auf der richtigen Straße „landet“.
Es wäre schön, wenn eine leicht verständliche manuelle Korrektur über das Portal möglich wäre und außerdem die Meßpunkte einem Datensatz zugeordnet werden könnten.
Die roten Linien sind im Übrigen gegenüber der Karte mit den Originaldaten leicht verändert (vgl. Sceenshot 3 mit usprünglichen Originaldaten aus dem obs)
sn1yinry KORRIGIERT.csv (1,5 MB)
sn1yinry.csv (1,5 MB)
VG Michael
@mfgutmann du könntest versuchen, die Koordinaten von einem der Punkte zu verwenden, bei denen das Verschieben funktioniert hat. Wo es genau war ist ja aufgrund des Rauschens nicht mehr zu sagen.
Allgemein die Anmerkung: Ein paar Messwerte liegen immer daneben aufgrund der GPS ungenauigkeit - Die Menschen, die mit den Daten am Ende arbeiten sollten das normalerweise wissen. Das muss dich aber nicht davon abbringen, deine Daten zu redigieren.
Wir denken dennoch schon länger darüber nach, einzelne Messwerte redigierbar zu machen. Es ist aber relativ viel Arbeit das Frontend entsprechend anzupassen. Das einfachste wäre vermutlich, falsch zugeordnete Messwerte zu vetoen. Aber es ist auch so, dass viele / die meisten Fahrer ihre Daten erheben ohne regelmäßig ins Portal zu schauen. Wer die Daten am Ende benutzt, müsste sich deshalb auch wenn es die Funktion gäbe darauf einstellen, dass es das (in der Wissenschaft ja eh immer übliche) Hintergrundrauschen gibt.
2 „Gefällt mir“
Hallo zusammen,
ich habe es nach schier endlosem Probieren geschafft, alle Werte auf die richtige Straße zu bringen. Im Trail and Error - Verfahren die Originaldaten anzupassen macht auf Dauer keinen Spaß - zumal die Google Maps Koordinaten offensichtlich abweichen und kaum brauchbar sind. Gibt es eine bessere Quelle für korrekte Standortdatenermittlung?
Das mit dem Hindergrundrauschen möchte ich nicht akzeptieren, wenn Messwerte falschen Straßen zugeordnet werden, sich dadurch ein falsches Bild ergibt und damit die Ergebnisse angreifbar sind. Schließlich will ich die Stadtverwaltung auf gefährliche Straßenzüge hinweisen und fahre nicht zum Spaß mit dem Gerät herum. Dann müssen die Daten auch den richtigen Straßen zugeodnet sein. Wenn ich einzelne Punkte in der Karte korrigieren muss, ist das kein Problem - es sollte nur etwas leichter möglich sein.
VG Michael
2 „Gefällt mir“
Es gibt den Wunsch schon länger, aber er ist nicht trivial umzusetzen, natürlich musst du dich damit nicht abfinden. Die Entwicklung des Portals findet hier statt - vielleicht möchtest du dich dort in der Softwareentwicklung einbringen, damit das Feature schneller realisiert werden kann. Aus Erfahrung kann ich sagen, dass das manchmal der beste Weg ist, ein Wunschfeatuere ins Portal zu bekommen.
Für die Standortermittlung könntest du die Openstreetmap versuchen - Rechtsklick „center here“ und dann die Koordinaten in der Url ablesen. Die Openstreetmap verwenden wir auch zum Mapping der Events auf Straßen, sie sollte also von den Koordinaten der OpenBikeSensor Karte entsprechen.
Auch einfach wäre vermutlich die Fehlschläger zeilen im csv wegzuwerfen - Geht mutmaßlich so viel schneller als neue koordinaten zu finden, dass man regelmäßig noch eine weitere Messfahrt unterbekommt in der Zeit, in der man sonst am CSV rumeditiert und am Ende trotzdem mehr Messwerte raus bekommt.
Alternativ könntest du schauen, ob du mit einem teureren GPS-Modul (Die Nachfolger M7N/M8N gibt es im gleichen Formfaktor) weniger Querschläger bekommst. Bei den GPS-Modulen ist die Streuung gewaltig, ggf. kann also sogar ein anderes M6N Besserung bringen.
1 „Gefällt mir“
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