Martin – leistungsstarker Echtzeit-Vektorkachel-Server auf PostGIS-Basis

Realistische Probleme bei der Umsetzung von Kartendiensten

Wenn man Karten normalerweise selbst implementieren will, stößt man meist auf die folgenden drei Punkte.

1. Der mühsame Umgang mit Datenaktualisierungen

• Problem: Ein neues Gebäude wurde zur DB hinzugefügt, aber um die Karte neu zu zeichnen (Tile Generation), muss jedes Mal ein mehrstündiger Vorverarbeitungsprozess durchlaufen werden.
• Martins Ansatz: Es gibt überhaupt keinen Vorverarbeitungsprozess. In dem Moment, in dem der Nutzer die Karte betrachtet, werden die neuesten Koordinaten aus der DB gelesen und sofort gerendert.

2. Die Grenzen der Server-Ressourcen

• Problem: Kartendaten sind groß und es gibt viele Anfragen, sodass der Server leicht abstürzt oder langsam wird.
• Martins Ansatz: Durch die für die Sprache Rust typische Low-Level-Kontrolle wurde der Speicherverbrauch extrem reduziert. Selbst Server mit geringer Ausstattung halten viele Anfragen aus.

3. Fragmentiertes Datenmanagement

• Problem: Manche Daten liegen in PostgreSQL, andere in großen Dateien (MBTiles); dadurch entstehen mehr Verwaltungspunkte.
• Martins Ansatz: Ein einzelner Server liest mehrere Datenformen gleichzeitig und führt sie in einem einheitlichen Format zusammen. Entwickler müssen sich nicht darum kümmern, wo sich die Quelle befindet, sondern nur eine API aufrufen.

4. Der Aufwand für zusätzliche Konfiguration

• Problem: Um eine Karte anzuzeigen, braucht man neben Tile-Daten auch Fonts, Icons, Style-Dateien und vieles mehr.
• Martins Ansatz: Solche zusätzlichen Assets können innerhalb des Servers selbst erzeugt oder ausgeliefert werden. Es ist keine zusätzliche Serving-Konfiguration nötig.

---

Das ist eher ein Utility, das den ganzen lästigen Zwischenaufwand übernimmt, bis die Daten auf dem Bildschirm erscheinen. Es ist ein Projekt, das die wiederkehrende Plackerei reduziert, die beim Aufbau eines GIS-Systems von Grund auf entsteht.