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. 
Man sieht hier, dass die Straßenzug-Zuordnung der Events noch nicht ganz funktioniert Die SQL-Query war schuld, ich habe sie repariert. Nun schaut’s so aus: 
Aber das finden wir auch noch raus.
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:
Ein paar Nachteile möchte ich natürlich auch nicht verheimlichen:
Wir experimentieren bei Teckids sehr viel damit, Dinge wie IoT per Matrix zu machen.
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
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:
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
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
Die Migration ist im Moment ungefähr so:
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
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… 
).
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.
Gute Nachrichten: Es gibt jetzt die Möglichkeit, das Portal als einen einzelnen Docker-Container laufen zu lassen: API, Frontend und Worker, alles drin. Dazu braucht es dann eine PostgreSQL und den Keycloak. Der Keycloak kann auch so konfiguriert werden, dass er in die PostgreSQL schreibt, dann braucht man auch nur für die ein Backup (und für das Filesystem mit den Upload-Dateien). Das tollste ist, dass die API dann die config.json für das frontend generiert und on-the-fly ausliefert, und die URLs sind nicht mehr so kompliziert
Wenn ich jetzt noch die OpenMapTiles-Tools da rein installiert bekomme, sparen wir uns noch ein weiteres image. Und dann noch schauen ob ich die Funktionalität vom tileserver-gl auch in Python abbilden oder importieren und integrieren kann 
Der Umbau klingt spannend. Also wir haben in Ulm ca ~25 User im Datenportal die alle einen eigenen Account eingerichtet haben. Das waren Nutzer die sich die 10 OBS für einen Zeitraum ausgeliehen haben. Damit können sie ihre privaten tracks sehen und selbst entscheiden welche die public machen wollen. Ich nehme an das die Hälfte sich nicht mehr in das Datenportal mit dem eigenen account sich einloggt. Aber die andere Hälfte wird noch aktiv damit arbeiten. Also ein Übertrag wenn möglich wäre ist es hilfreich, ansonsten müssten wir halt die accounts wirklich manuell transferieren.
Großartige Nachrichten: Ich habe noch einen Service ausbauen können, nämlich den Tileserver. Stellt sich heraus, dass die generierten .mbtiles Dateien nichts anderes als SQLite-Datenbanken sind, in denen die fertigen Tiles nach XYZ-Koordinaten und im .gz.pbf-Format direkt vorliegen. Das ist sehr einfach zu extrahieren und über HTTP auszuspielen.
So bleiben drei Docker-Services:
Plus ein Docker-Container mit den openmaptiles-tools, um die .mbtiles-Datei zu generieren. Vielleicht bekomme ich die auch noch irgendwann in das Portal-Image installiert, die sind zum Großteil auch Python. Leider auch ein kleiner Teil Node.js und das ist immer ein bisschen nervig, finde ich, hybride Images zu bauen (Python + Node). Mal sehen.
Als nächstes schreibe ich dann wohl das User-Migration-Skript.
So, habe eine bessere Lösung als die API anzusprechen: Das import-skript schreibt eine JSON-File mit den Username/Email Kombinationen, sowie dem E-Mail-Validierungs-Zustand, die einfach in Keycloak importiert werden kann. Der größte Vorteil daran ist, dass die Administratorin die Datei erst bearbeiten kann und Leute entfernen oder verändern, und dann auch die Kontrolle hat über Duplikate beim Import.
Hat hier jemensch Lust die Migration und die neue API zu testen? Ich helfe auch gern via Screensharing.
Und wieder einen Schritt weiter:
Das heißt, es ist kein Schritt (mehr) nötig zur Kachelgenerierung. Track importieren → Gesamtkarte öffnen. Kein Cronjob jede Nacht, kein Aufwand für Portalbetreibende.
Ich befürchte, ich habe eben das Test-Portal zum Absturz gebracht. Habe viele Tracks aus Stuttgart hochgeladen und mir danach die Karte angeschaut. Bei einer Straßenabschnitts-Abfrage blieb die Seite dann hängen und antwortet seither nicht mehr… bzw. gibt jetzt eine 500 - internal Server Error zurück
