Visualisierung mit Zeitfilter eingabe möglichkeit

in Ulm haben wir eine Menge Daten von 2021 und bekommen neue von 2022 hinzu. Momentan werden alle zusammen angezeigt und das ist auch gut so. Nun aber kommen Anfragen auch von der Stadtverwaltung ob sich nach Einführung von verkehrtechnischen Maßnahmen sich die Messungen verbessert hätten. Dazu müßte ich in der Visualisierung den Zeitbereich einstellen können z.B: zeige die Visualisierung mit allen Daten bis 31.12.2021 und dann zeige die Daten ab 1.1.2022 bis 30.6.2022.
Gibt es sowas schon? Ich bin nur ein Nutzer der (echt tollen) Visualisierung und leider kein SW Guru der sich ein ‚magic script‘ bastelt :woman_mage:. Könnte man sowas bereitstellen (ist bestimmt ein gewisser Programmieraufwand notwendig um das im Menü anzubieten)
Ich denke dieses Feature wird in Zukunft immer öfter benötigt, um Daten vorher/nachher darzustellen. Und um Maßnahmen zu messen und zu beurteilen

3 „Gefällt mir“

Diese Idee wurde bereits in Github als Ticket angelegt :slight_smile:

Technisch ist das nicht trivial, aber ich habe irgendwann mal einen funktionierenden Prototypen hinbekommen. Das kann ich gerne, wenn ich die Zeit dazu finde, noch einmal herauskramen und zu Ende machen.

LG Paul

5 „Gefällt mir“

Da ich den Vorschlag auch schon gemacht habe, fänd’ ich das natürlich toll, diesen Folter zu haben. Wir haben unserem Mobilitätsamt für solche Fälle Exports vorgschlagen, die sie dann selbst sotieren müssen. Je nachdem wie die aufgestellt sind, fehlt dann die Visualisierung (ich hab’s z.B. plump nach xls konvertiert).

1 „Gefällt mir“

Wir haben uns hier in München mit Google Sheets einen Workaround gebaut: Ein Skript greift auf die exportierten JSON-Files zu und bereitet sie im Sheet auf. Mit Pivot-Tabellen lassen sich dann für einzelne Straßenabschnitte auch zeitliche und sonstige Vergleiche bauen. Das ist temporär eine gute Lösung, bei Interesse gerne kurz melden. Aber langfristig wäre das natürlich toll im Portal.

1 „Gefällt mir“

FYI das Ticket wurde bearbeitet und ein Pull-Request ist offen: https://github.com/openbikesensor/portal/pull/260

Falls das mal jemensch mit einer Entwicklungs- oder Testinstallation ausprobieren möchte, um Feedback zu geben :wink:

LG Paul

2 „Gefällt mir“

@gluap hat wohl unser Portal aktualisiert.
Da sind jetzt die Zeitfilter drin ( und ein paar andere schöne Sachen) Dank an @opatut und alle, die sonst evtl. noch mitgewirkt haben.
Ihr wisst, ich bin unersättlich: spricht was dagegen, die Zeitfilter auch für Menschen verfügbar zu machen, die nicht eingeloggt sind?
Ich denke da an unsere Freunde von Darmstädter Mobilitätsamt und so.
Aber so oder so, super Sache.
Noch mal Riesendank dafür

@Klaus In grenzen kann man durch geschickte Anwendung des Filters Tracks rekonstruieren, ich denke mal auch deshalb ist der hinter dem Login versteckt. Wenn du möchtest können wir dem Mobilitätsamt einen Login herstellen.

Genau, das wäre auch meine Alternative gewesen @gluap
Eilt aber nicht wirklich.

Da wäre dann vermutlich eine „saubere Lösung“ in Bezug auf Privatsphäre eher, dass eine gewisse Menge an Tracks oder Datapoints in der Visualisierung auf keinen Fall unterschritten werden darf. Das betrifft grundsätzlich ja auch spärlich befüllte Portale.
Aber im Endeffekt wird die Datenlage sowieso erst ab einer gewissen Menge aussagekräftig, also wäre das auch für die Kommunikation und Verwendung nach außen sicher nicht schlecht? :thinking:

@trainbird naja - Die Tracks werden ja in jedem Fall nicht personenbezogen ausgegeben, sondern nur „da ist mal je mand langefahren“ würde erkenntlich. „Da ist mal jemand langefahren“ ist aber ein Feature ohne das man die Daten nicht ordentlich bewerten kann. Deshalb gibt es nicht umsonst das Privacy Zone Feature, damit man nicht versehentlich seine start/zielkoordinaten exponiert. Selbst in stark frequentierten Portalen kann man die commute Wege, auf denen OBS entlang fahren leicht identifizieren - ganz ohne Zeitfilter, einfach weil es eine Strecke gibt, die schon 50 mal befahren wurde.

Die Beschränkung auf eine bestimmte Mindestmenge an Datenpunkten hilft auch wenig - Schließlich ist eines der anonymen Daten die wir seit eh und jeh herausgeben das anonyme „Überhohlevent“ mit Uhrzeit und Datum. Ob auf der Karte jetzt einer oder 50 davon zu sehen sind macht da wenig unterschied. Es ist unglaublich schwer, hier einen Filter zu finden, der gleichzeitig die Anonymität erhöht aber die Beantwortung von Forschungsfragen nicht verhindert.

Die Beschränkung der Segmentnutzungsanzeige könnte man unabhängig von den Zeitfiltern auf "nur segmente mit >=2 Befahrungen reduzieren. Dann wiederum könnten Schlaufüchse kommen die fragen „wenn das Segment nicht befahren wurde, wie kann da überholt worden sein!!11elf“, was die Glaubwürdigkeit der Daten in der Öffentlichkeit in mitleidenschaft ziehen kann. Ja - man kann dran schreiben wies berechnet wird, aber wenn jemand mit dreck schmeißen will liest er die Doku oft nicht so genau. Trotzdem ist das vielleicht ein sinnvoller Ansatz wenn man es gut visualisiert.

Schlussendlich kann sich jeder seinen tagesgenauen Zeitfilter bauen, indem er einfach regelmäßig die kumulierten Daten crawlt.

Genau die Anonymität war aber doch grade das Argument gegen einen offenen Zeitfilter?

Wie sollen sie auf Überholvorgänge kommen können, wenn keine angezeigt werden?

Abgesehen davon, dass die Daten ja eh nicht belastbar sind, wenns zu wenig Messungen gibt. Sowohl in Zeitfilteransicht als auch sowieso immer. War auch mein Verständnis von der Philosophie „Die Sensoren sind nicht 100% verlässlich, aber durch die Masse wird das wieder gerade gerückt“ die ich voll und ganz unterstützen kann. Drum is es doch fast unerlässlich, dass die Segmente >=2 Messungen haben sollten. Sonst kommen schlaufüchse und sagen „ja, ich bin da aber schon mal gefahren und da war noch nie was!! Ergo sum: Meine Aussage gegen Messung eines nicht ganz immer richtig messenden Sensors = Daten sind mist!“

Die Events kannst du ja nicht wegfiltern, nur weils da bloß zwei Punkte auf dem segment gibt. Und wenn dann ein eventpunkt da ist, das Segment aber „null anzeigt“ sieht es halt inkonsistent aus.

Ich finde dass die Konsistenz wichtig ist und es nicht die Aufgabe der Plattform ist, die daten zu kuratieren. Das einzige filtern was ich zulässig finde ist das, was zur anonymisierung der Daten notwendig ist. An der Stelle ist aber fraglich ob das überhaupt der Fall ist, deshalb finde ich die Lösung es hinter die Schranke zu legen ok.

2 „Gefällt mir“