Aktueller Stand und weiterer Plan

Design & Entwicklung Portal & Datenverarbeitung
#22

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 :wink:

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 :heart_eyes:

1 „Gefällt mir“
#23

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.

#24

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. :tada:

So bleiben drei Docker-Services:

  • PostgreSQL
  • Keycloak
  • API (mit Frontend, Worker und Tileserver drin)

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.

2 „Gefällt mir“
#25

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.

Portal: aktueller Status und regionale Portale?
#26

Und wieder einen Schritt weiter:

  • Das API-Image enthält jetzt die openmaptiles-tools, un es gibt ein Python-Skript das im Image gestartet werden kann, dass dann die PostgreSQL Datenbank präpariert für die Kachel-Verarbeitung.
  • Die API kann nun direkt aus der Datenbank, aus dem aktuellen Datenbestand, die Kacheln generieren und per HTTP ausspielen.

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. :tada:

4 „Gefällt mir“
#27

Ein Beitrag wurde in ein neues Thema verschoben: Wie setze ich mein eigenes Portal auf?

#28

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