Aktueller Stand und weiterer Plan

Hallo zusammen, ich ergreife einfach mal die Gelegenheit den aktuellen Stand des Portals zu beschrieben, sowie was so in nächster und ferner Zukunft geplant ist, und wann wir endlich wieder Daten hochladen können.


Wie weit ist die Software?

Kurzfassung: Nicht weit. Mit dem Rewrite der Anwendung habe ich hauptsächlich Technologien umgestellt, sodass wir in Zukunft mit mehr Leuten daran arbeiten können. Jetzt ist das Portal auch wirklich „unser Code“, davor war es ziemlich zusammengestückelt aus anderen Projekte usw…

Die größte und wichtigste Änderung daran ist, dass die Python-Skripte („FACE“) nun vom Portal verwendet werden, um die Daten zu interpretieren und zu verarbeiten, und nicht eine eigene, getrennte, und in JavaScript implementierte Fassung der „gleichen“ Logik.

Mehr ist leider noch nicht da. Das heißt aber auch, dass ihr euch alle gern einbringen könnt.

Was steht in nächster Zeit an?

Prinzipiell hauptsächlich Datenverarbeitung, hier fehlt vor allem ein gutes Konzept. Dann ein paar Features, die wir einfach brauchen, um nicht bei steigenden Userzahlen sofort zusammenzubrechen.

  • Allgemeines Konzept der Datenverarbeitungs-Pipeline. Es gibt jetzt einen „Worker“ der Verarbeitungsjobs entgegennimmt, und so im Hintergrund z.B. die Tracks importiert. Da fehlt aber dann noch die Anonymisierung und Aggregation. Wann und in was für Einzelschritten das passiert (insbesondere damit nicht immer alles von vorn berechnet werden muss, wenn irgendwer einen Track hochlädt) sollten wir mal gut definieren und dann umsetzen.
  • obs-face sollte mal optimiert werden, dass es schneller rechnet. Vielleicht mit numpy oder so, nicht jeden Punkt einzeln ausrechnen.
  • Privacy Zones / Privacy Settings: Wir sollten dem Portal bald beibringen, das gut konfigurierbar zu haben und auch anzuwenden.
  • Und wenn jemand richtig Bock hat die visulaisierung auf irgendein richtiges GIS umzustellen, damit wir die Maps kacheln können und eine schön performante globale Kartenvisualisierung erstellen können – das wäre ein ziemlich alleinstehendes Projekt und sehr kompliziert glaube ich, aber auch seeeehr cool, so langfristig.
  • Und nicht zu vergessen, müssen wir etwas „Housekeeping“ machen, inbesondere wäre es schön, Migrationen schreiben zu können. Da jetzt alle schon viele Installationen exisiteren, und Leute ihre Tracks hochladen, wird eine Lösung dafür langsam Zeit :woman_shrugging:

Wie kann ich helfen?

Schreib doch einfach mal hier, oder in Slack, oder auf Github, dass du helfen möchtest. Die Sommerpause ist vorbei und wir fangen wieder an, die Arbeit zu koordinieren. Los geht’s!

Wo bleibt die „offizielle“ Installation der OpenBikeSensor Community?

Früher oder später werden wir eine stabile „offizielle“ Installation der Portalsoftware anbieten, auf der sich alle einen Account anlegen und dann fleißig Daten hochladen können. Bisher gibt es zwar eine Installation, die ist allerdings in Testbetrieb und wird nicht öffentlich beworben, insbesondere da wir sie jederzeit zurücksetzen können müssen. Außerdem sind wir noch dabei, die datenschutzrechtlichen Details auszuarbeiten. Leider können wir ohne diese nicht starten, und so richtig auskennen tut sich auch niemand.

Wann seid ihr endlich fertig?

Keine Ahnung. Aber wenn du und deine Freund:innen jetzt loslegen wollen, Daten hochzuladen, siehe :arrow_down:

Der mittel- und langfristige Plan: Dezentralisierung und Föderation

Diese irgendwann verfügbare „offizielle“ Installation kann von allen genutzt werden, sobald sie fertig wird. Allerdings wünschen wir uns, dass Regional- und Projektgruppen sich ihre eigene Installationen aufsetzen, auch gern jetzt schon. Dabei helfen wir gern. Das Ziel ist, damit die Verantwortung für die Daten zu streuen (Dezentralisierung) und unabhängige Weiterentwicklungen zu ermöglichen (Innovation, yeah!).

Langfristig werden wir der Software dann beibringen, dass die anonymisierten und vorverarbeiteten Daten aus ganz vielen unabhängigen Installationen (die ganzen Regionalgruppen, Projekte, und die „offizielle“ Instanzen) automatisch zusammen in einen großen globalen Datenpool fließen. Bis dahin ist es aber noch ein weiter Weg, und die Schnittstellen dafür sind noch nicht entworfen. Auch hier kann gerne bereits losgearbeitet werden, hauptsächlich erstmal auf konzeptioneller Ebene, bevor es tatsächlich an eine Umsetzung geht.


Ich hoffe, dieser Überblick ist hilfreich, und dass sich jetzt eine Handvoll Leute findet die nach und nach die ganzen schönen Features oben baut. Dann haben wir hoffentlich in ein paar Wochen bis Monaten eine globale Karte die sich täglich updated, und alle können dezentral ihre persönlichen Tracks verwalten. :rocket:

4 „Gefällt mir“

Moin!

Dank des Supports in Slack habe ich letzte Woche erfolgreich das Portal in Betrieb nehmen können, aber ich würde gern noch besser verstehen wie es tickt und der weitere Fahrplan dafür ist.

Mir ist z.B. aufgefallen, dass im Frontend eine roads.json von einer OBS Domain nachgeladen wird und derzeit, zumindest in meiner Install, eine ähnliche Datei nicht automatisch durch das Portal erzeugt wird.

Nun frage ich mich, wie hier der konkrete Plan für die Zukunft ist. Das Nachladen aller ausgewerteten Tracks mittels JSON dürfte mittelfristig nicht mehr möglich sein, je nach dem wie aktiv die User des Portals sind. Irgendwann wird die JSON Datei riesig und das live Rendern eines HTML-Canvas-Layers über openstreetmap zu Performanceproblemen führen.

Als vor vielen Jahren WebSockets in Browsern einzug hielten und NodeJs gerade der neue „heisse Scheiss“ :wink: war, habe ich mal ein endloses HTML5 Canvas gebaut auf dem jeder, ähnlich wie in Paint, malen konnte.
Dabei hatte ich anfangs auf MongoDB und geospatial Indexe gesetzt, was aber leider nicht sehr gut performte. Am Ende hatte das gesamte Canvas in Quadrate gesplittet und diese ähnlich wie Google Maps vorgerendert beim Scrollen nachgeladen. Die Daten hatte ich in Mysql gespeichert und die Tabelle partitioniert. Das ging ganz gut, aber der allein der Index der Tabelle wuchs schnell an.

So eine Lösung mit festen Unterteilungen der Karte könnte ich mir auch für das Portal gut vorstellen. Beim Scrollen auf der Karte würde das Frontend dann den aktuellen Viewport per Ajax an die API übermitteln und dann vorgerenderte Tiles vom Server nachladen. Der einzige Nachteil dieser Lösung ist, dass man relativ schnell viele Bilder auf dem Server speichern muss. Das Aktualisieren der Bilder könnte der Worker automatisch übernehmen wenn er Tracks auswertet. Der Vorteil ist, dass das Frontend relativ schnell Inhalte lädt und nichts im Browser gezeichnet werden muss. So könnte man relativ leicht durch eine deutsche Großstadt scrollen und sich einen Überblick verschaffen wo Problemstellen sind.

Das war jetzt mal „laut gedacht“, weil ich die Problematik aufgrund meiner Erfahrungen relativ gut nachvollziehen kann und wirklich sehr daran interessiert bin zu erfahren, welchen Weg ihr hier mittel/langfristig einschlagen wollt.

Hi @sirtificate, danke für deinen Beitrag!

Das ist korrekt. Dafür gibt es noch keinen automatischen Prozess, die roads.json wird von den OBS-Scripts erstellt aber eben nicht automatisch und inkrementell von der API. Das ist Work-in-Progress. Ich hatte es nur schonmal in die Karte auf der Startseite eingebunden um einen Vorgeschmack zu bieten auf das was kommt. Wenn du Lust hast kannst du die bei deiner Installation getrennt generieren (z.B. in einem cronjob) und dann verlinken.

Das ist vollkommen korrekt, und deine Erfahrungen sind hier sehr wertvoll. Ich habe das schon vermutet, dass das früher oder später – eher jedoch früher – zum Problem wird.

Das schöne ist hier glaube ich, dass das ja eine ziemliche Standardanwendung in Sachen Visualisierung geographischer Daten ist. Dafür gibt es im OSM-Umfeld genug Lösungen und Tools, um genau das zu erreichen. Deine vorgeschlagene Kachel-Lösung gibt es quasi 1:1 so dort zu finden.

Das sieht dann ungefähr so aus:

  • Die Daten nicht in ein großes JSON, sondern eine richtige Datenbank mit Unterstützung für geographische Primitive und Operationen speichern (z.B. postgis).
  • Mithilfe eines Open-Source Tools Vektor- und/oder Rasterkacheln generieren. Tools gibt es genug zur Auswahl.
  • Die Kacheln wie üblich über HTTP ausspielen.
  • Das Ergebnis entweder ad-hoc rendern (Vektorkacheln) oder eben nur als Bilder anzeigen (Rasterkacheln). Das können die Karten-Implementationen beides sehr gut (leaflet, openlayers, …).

Ich habe bei Recherchen mal das hier gefunden: Custom Vector Tiles from PostGIS. Das „OpenMapTiles“ Projekt sieht vielversprechend aus. Was ich an tooling aus dem OSM-Umfeld kenne ist zwar in der Regel sehr mächtig, aber auch sehr frickelig zu benutzen. Ich hoffe, dass OpenMapTiles etwas moderner daher kommt und einfacher zu bedienen ist. Aber wenn es nicht die richtige Wahl ist, finden wir sicher eine Alternative. Davon gibt es wie Sand am Meer :wink:

Ich habe gestern tatsächlich mal angefangen, diesen Weg einzuschlagen und testweise zu sehen, wie weit ich damit komme. Das ist erstmal ein bisschen Umbau, dass ich eben das Ergebnis des CSV-Imports nicht in JSON-Dateien sondern schön in eine PostgreSQL schreibe. Und dann werde ich schauen, wie ich das in diese Tools integriere, und welches Tool sich da am besten eignet. Das kann ich in den nächsten Tagen dann genauer beantworten und werde gern hier berichten.

Dieser Weg über richtige Datenbank scheint mir auch künftig zielführender. Wenn wir mit der Föderation anfangen, werden wir auch größere (hoffentlich binär-)dumps machen, evtl sogar Changesets. An der Stelle würde ich dann überlegen eines der standardisierten OSM-Formate einzusetzen, einfach um das Rad auch dort nicht neu erfinden zu müssen.

FYI meine Lapop-Tastatur hat leider einen Wackelkonak, was das weiterarbeiten unerwegs schwer mach. Ich bin erst wieder nächste Woche zu Hause, und werde wohl dazwischen nich so viel weier enwickeln können (wer rausfindet an welcher aste der Wackelkontakt is bekomm ein :heart: :D).

Was ich bis zum Defek erreich habe:

  • Mi osm2pgsql die OSM Rohdaen in eine eigene PostGis imporier, und zwar nur die relevanen Informaionen (Straßenabschnie, mi abgeleieter zone und weieren wichigen tags) .
  • Nach dem Verarbeien eines einzelnen racks werden die Überholmanöver ebenfalls in eine Tabelle der SQL geschrieben.
  • Ein SELECT ... JOIN Statement kann Sraßenabschnie zusammen mi min/max/avg/… Saistiken erzeugen. Das könne zur Optimierung auch als „materialized view“ angeleg werden.

Ich werde vielleich noch testweise Vekorkacheln aus dieser Daenbak ableien, z.B. mi dem oben verlinken openmaptiles. Wenn das alles theoreisch klapp, werde ich mich um die Deails kümmern. Ich habe eine Menge Features der bisherigen Visualisierung ersmal uner den tisch fallen lassen für einen ersen test. Das komm dann nach, wenn das Konzep aufgeh. Sieht aber ganz danach aus. :tada:

So viel zum kurzen Zwischenstand. Bis bald.

1 „Gefällt mir“

Neue Tastatur, neues Glück! Ich kann endlich von meinem Fortschritt berichten :blush:

Das Erstellen von Vektorkacheln hat ganz wunderbar funktioniert. Ich habe also aus technischer Sicht alle Komponenten zusammen, um

  • automatisch
  • effizient
  • mit Open Source Software & unabhängig von Dirttanbietern
  • vermutlich langfristig kompatibel

die hochgeladenen Tracks zu verarbeiten und anzuzeigen. Dafür werden verwendet:

  • postgresql (mit postgis und hstore extensions)
  • osm2pgsql zum Importieren von OSM-Straßenzügen (keine Abhängigkeit von der Overpass API mehr :tada:)
  • openmaptiles-tools
    • welches imposm zum importieren von OSM-Daten verwendet
  • tileserver-gl, um die Kacheln, Schriften, Kartenstyles, … auszuspielen
  • maplibre-gl-js, ein drop-in-replacement/fork von mapbox-gl-js, aber vor der v2 geforked und damit noch Open Source. Eine Kartenbibliothek für den Browser, die Vektordaten mit WebGL rendert.
  • ein eigenes Python Script, welches obs.face importiert, den Track verarbeitet, und dann in die postgresql-Datenbank schreibt (kommt bald ins Portal-Repo)

Erstellt werden mit diesen Tools:

  • eine Tabelle in der postgresql mit OSM-Straßendaten aus den importierten Regionen
  • eine Tabelle in der postgresql mit den Überholmanövern, zugeordnet zu den Straßenabschnitten
  • einige Funktionen in der postgresql, die für die Berechnung der Vektorkacheln benutzt werden
  • eine .mbtiles-Datei, die alle Vektorkacheln enthält, auf Zoom-Stufen 0 bis 14
  • daraus werden „live“ vom tileserver die .pbf-Kacheln erstellt im MVT-Format (glaube ich) – Theoretisch könnten hier auch Rasterkacheln gerendert werden mit einem beliebigen Renderer der .mbtiles oder .pbf lesen kann… ich finde Vektorkacheln aber ganz gut da sie sehr flexible Visualisierung ermöglichen (siehe Mapbox Styling Docs) – vieles davon kann maplibre-gl-js auch.

Ich werde mich nun als nächstes daran machen,

  • das getestete Vorgehen genau zu dokumentieren,
  • mein zusammengehacktes Beispiel zu sinnvollem Anfangs-Code zu verbessern und zu pushen,
  • das nächste Ziel zu definieren und alle technischen Details zu finalisieren, um dann endlich
  • einzeln durchführbare Aufgaben als Issues anzulegen.
5 „Gefällt mir“

7 Beiträge wurden in ein neues Thema verschoben: Neues Portal sendet keine Registrierungsmail

Ich kauf Dir ein t, und weil der Beitrag 20 Zeichen lang sein muss: tTTtTttTTee

3 „Gefällt mir“

So kann das ganze dann übrigens aussehen:

Die Daten werden im Browser gerendert, aus den Kacheldaten, die aus der PostgreSQL gerendert werden, welche vom processing script befüllt wird. :tada:

Man sieht hier, dass die Straßenzug-Zuordnung der Events noch nicht ganz funktioniert :confused: Aber das finden wir auch noch raus. Die SQL-Query war schuld, ich habe sie repariert. Nun schaut’s so aus: :slight_smile:

3 „Gefällt mir“

Hallo zusammen!

Dank Hilfe auf Twitter habe ich nun den Weg in die offen zugängliche Community gefunden (Slack ist keine Option für mich, da es junge Menschen gezielt diskriminiert).

Hier würde ich mich gerne einbringen und werfe Matrix als Backend in den Raum. Matrix kennt der eine oder andere vielleicht als Chatplattform, aber eigentlich ist es eine dezentrale JSON-Datenbank mit Föderation. Hier einige Vorteile der Nutzung von Matrix:

  • Viele Communities, die etwas mit freoer oder offener Software/Daten/etc. machen, haben schon Matrix-Server
    • Wenn sie noch keinen haben, kann man mit OpenBikeSensor auch gleich noch die Föderation beim Chat antreiben :wink:
  • Man muss sich nur noch das JSON-Schema überlegen, den ganzen Föderations-Kram kann man sich sparen, denn der ist schon fertig
  • Es gibt Nachrichten und State-Updates. Damit lassen sich Live-Broadcasts abbilden, aber auch Statistik-Snapshots, die dann direkt im Raum verfügbar sind

Ein paar Nachteile möchte ich natürlich auch nicht verheimlichen:

  • Man muss einen Matrix-Homeserver installieren, oder einen von jemand anderem benutzen, der die Übertragung von im Zweifel sehr vielen IoT-Daten erlaubt
    • Allerdings ist das vielleicht sogar einfacher, als ein OBS-spezifisches Backend mit Föderation aufzusetzen
  • Matrix ist momentan nicht besonders schnell für sehr viele, sehr kleine JSON-Nachrichten, aber daran wird gearbeitet

Wir experimentieren bei Teckids sehr viel damit, Dinge wie IoT per Matrix zu machen.

3 „Gefällt mir“

Hi @natureshadow, schön dass du hier bist!

Deinen Vorschlag von Matrix für Föderation hatte auch @preya schon in den Raum geworfen. Ich bin generell daran interessiert (wir überlegen ja auch, für Chat-Kommunikation von Slack dorthin umzuziehen), aber bleibe skeptisch ob es die richtige Technologie ist. Ich mache mir insbesondere Sorgen aufgrund der Datenmenge. In meiner Vorstellung geht es ja nicht um live-Daten, und die Datenpipeline ist auch unidirektional.

Meine Idee einer naiven Implementation wäre eher vergleichbar mit dem Keyserver-System von GPG (natürlich ohne dessen Probleme der Unlöschbarkeit etc.), bei dem die Plattformen, wie auch immer, ihren verarbeiteten Datensatz veröffentlichen, und ein zentraler „Pool“ sich diese Daten jeweils herunterlädt und zusammenführt in einen Gesamtdatensatz. Ich glaube, die Daten sollten nicht als JSON vorliegen, hier haben wir jetzt schon Platz- und Performanceprobleme. Aber vielleicht hilft ja Matrix bei der Koordinierung und Verwaltung dieses Schemas, während die tatsächlichen Daten anders formatiert und über einen anderen Kanal übermittelt werden.

Vielleicht haben du und @preya ja Lust mal zu dritt (oder vielleicht wollen noch mehr?) darüber zu diskutieren. Ihr scheint euch da gut auszukennen, da würde ich mich sehr freuen das vorgestellt zu bekommen.

LG

2 „Gefällt mir“

Können wir gerne machen, ich brauche nur 2-3 Wochen Vorlauf für Terminabstimmungen für synchrone Meetings.

Ich habe mit Matrix bisher auch keinerlei Berührungspunkte gehabt und wäre daher bei dem Meeting auch gerne dabei, um mehr darüber zu verstehen, da ich mangels Zeit mich da derzeit auch nicht von Null einarbeiten kann.

Neuer aktueller Stand zur Portalentwicklung:

  • Umbau der API auf Python
    • Nutzt SQLAlchemy
    • Integriert direkt mit obs-face
    • Nutzt zur Datenverarbeitung die importierten Roads aus der SQL statt der Overpass API (sehr schnell!)
  • Migrationsscript MongoDB → SQL funktioniert auch schon
  • Migrationsstrategie MongoDB → Keycloak ist implementiert
    • User müssen neuen Account von Hand erstellen
    • Der wird anhand der Email-Adresse beim Login dem alten Account zugeordnet

Als nächstes update ich mal den Developer Guide, dann den Installation Guide, und dann kann ich mal mit ein zwei von euch ausprobieren ob wir das bei euch zum Laufen bekommen :wink:

Ein Plan den ich noch habe, um das ganze einfacher zu Betreiben zu machen: Für den Produktionsbetrieb möchte ich das Frontend und die API in einem Prozess laufen haben, der Python Sanic Prozess kann ja problemlos die Frontend-Files statisch ausspielen. Dann haben wir weniger Routing-Themen, und die Portalbetreiber:in muss nur noch einen einfachen Reverse Proxy mit TLS Termination konfigurieren. Die Frontend-Config-File würde dann auch dynamisch vom Python Server generiert und es bräuchte insgesamt nur noch eine Config-Datei :slight_smile:

Die Migration ist im Moment ungefähr so:

  • Alles herunterfahren, nur MongoDB anlassen
  • Neue images bauen
  • Datenbank-Reset-Script ausführen (Schema erstellen)
  • MongoDB → SQL Migrationsscript ausführen
  • MongoDB herunterfahren
  • Keycloak starten und Konfigurieren
  • API (neu) konfigurieren
  • API und Worker starten

Geht eigentlich, oder?

Nach dem ganzen Umbau sind die Track-Daten und Überholdaten dann in der SQL-Datenbank, und die von mir oben beschriebenen Tools können die Vektorkacheln für die Visualisierung ableiten. Plus, die ganze Anwendung ist stabiler, weil sie nicht mehr so chaotisch aus verknüpften Technologien besteht. Neue Features sind dann ganz schnell gebaut :wink:

2 „Gefällt mir“

Ein Beitrag wurde in ein neues Thema verschoben: Neues Chat-System für die Community

Ich habe ein Dev-Setup, welches wir zum Testen sehr gerne verwenden können.

Wollen wir eigentlich Portalen anbieten, unseren zentralen KeyCloak verwenden zu können? Dann müssten wir nur einen Client anlegen und der kann dann konfiguriert werden. Das initiale Einrichten ist nicht ganz trivial, wenn man nicht schon mal gemacht hat. Da wird man ziemlich erschlagen…

Ich wäre auch gern als Versuchskaninchen dabei und würde zuerst unsere Schatteninstanz migrieren. Zentralen Keycloak sieht unser ADFC vermutlich kritisch - Derzeit wollen wir ja nur Leute reinlassen, die unsere Datenabtretungserklärung unterschrieben haben, außerdem müssen wir unsere existierenden User mit rüber nehmen.

Das läuft dann so ab, dass ihr die entweder manuell übetragt, oder dass sie sich einen neuen Account anlegen und der nach Username + Email gematched wird beim Login. Also ihr müsstet denen schon sagen dass sie die gleiche Kombination benutzen müssen, sonst wird ein neuer User angelegt und ihr müsstet von Hand die Tracks & Kommentare in der SQL dem richtigen User assoziieren (dafür könnte ich ein mini-script schreiben… :thinking:).

Wollen wir eigentlich Portalen anbieten, unseren zentralen KeyCloak verwenden zu können?

What’s the point? Also ja vom Managementaufwand ist dasüberschaubar, technisch sehr einfach, aber dann liegt zumindest meine E-Mail-Adresse und mein Username ja woanders als meine Daten, aka ich hab 2 Betreiber:innen und nicht nur 1. Macht irgendwie wenig Sinn, zumal ich ja vermutlich nur in ein Portal hochlade. So oder so wäre das optional, natürlich kann jede:r Betreiber:in ihre eigenen Keycloak hosten – nur ohne Keycloak geht es ab v0.3 nicht mehr.

Tatsächlich haben wir nur 5 oder 6 von 25 Nutzern, die aktiv einen eigenen Account nutzen, der Rest ist mit Mailadressen „obs01“ - „obs20“@adfc registriert und hat die Geräte fertig konfektioniert und ohne Passwort bekommen. Die Nutzer konfigurieren bei der Geräteübergabe eine Privacyzone und die Assoziation Personendaten → GeräteID wird bei Rückgabe des OBS weggeworfen, um die Daten möglichst anonym zu halten.

Ich schätze der Weg wäre dann dass ich ein Script schreibe, das die „bulk“ Nutzer mit der gleichen Email – Password Kombi im Keycloak erzeugt, und den anderen fünf sage ich Bescheid.

Wenn du dir hier eh die Mühe machen möchtest ein Skript zu schreiben: Vielleicht kannst du ja die API von Keycloak ansprechen, und das ganze ins Migrationsskript api/tools/import_from_mongodb.py (branch postgis) einbauen, sodass nicht nur User in der PostgreSQL angelegt werden sondern mit der Username/EMail Kombination auch ein User im Keycloak angelegt wird – die Leute müssten dann nur einmal ihre Passwörter resetten. Ich gehe davon aus, dass du das – sogar in Bulk – im Keycloak ebenfalls triggern kannst. Die User würden dann über den Keycloak sub in der PostgreSQL assoziiert und wir können den Username/Email-rematch-Mechanismus doch wieder ausbauen.