Reiseführer Banat & România — technische Roadmap

Vom Atlas zur QField-App: Datenmodell, Signatur-Pipeline, Cloud-Verteilung und der Vier-Wochen-Plan. Schwerpunkt Banat, Abdeckung ganz Rumänien.

ZweckArbeitsgrundlage für die Umsetzung ⋅ ergänzt die Entscheidungs-Präsentation VerfasserJan Paki ⋅ sternprodukt.de WerkzeugeQGIS ⋅ QField ⋅ eigene QFieldCloud-Instanz ⋅ GDAL ⋅ Ruby Stand7. August 2026 ⋅ Fassung 1.0 ⋅ 4 Seiten

Jan Paki ⋅ jan ⋆_ℏ sternprodukt.deSeite 1 von 4

Roadmap Reiseführer ⋅ Fassung 1.0Inhalt & Architektur

Inhalt

1Architektur: eine Datenquelle, zwei Ausgaben2

2Datenmodell: das GeoPackage3

3Bahn: GTFS-Endpoint und Deep-Links3

4Meilensteine: vier Wochen bis zum Praxistest4

5Risiken und offene Punkte4

1Architektur: eine Datenquelle, zwei Ausgaben

Alles Fachliche liegt in genau einem GeoPackage — der Single Source of Truth. Die Atlas-Blätter (Druck) und das QField-Projekt (App) sind zwei Builds desselben Bestands — wer die Karte pflegt, pflegt die App mit. Die App bleibt strikt offline-first; alles Live-artige (Fahrpläne, Routing) verlässt sie per Deep-Link in den Browser. Der Schwerpunkt Banat ist kein eigener Datenbestand, sondern eine dichtere Erfassung derselben Layer — Timișoara, Reșița, Recaș, die Hanf-Regionen von 1980.

reisefuehrer.gpkg (EPSG:32635 — UTM 35N, Meter)
 ├─ Fachlayer (Abschnitt 2)
 │
 ├──→ Druck   d3-Blätter + signaturen.js        (bestehend)
 └──→ App     QGIS-Projekt + .qml-Stile
              └─ QFieldSync-Paket + MBTiles ──→ QFieldCloud (eigene Instanz)
                                                 └──→ Geräte (Sync bei WLAN)

Plan B (Sync): Syncthing — zwei Handys finden sich selbst,
               kein Server, kein Account, einfach da

Die Signaturen kommen aus dem Signaturenkatalog des Atlas (atlas/signaturen.js) und werden einmal als .qml-Stile übersetzt; die Basis liegt im QGIS-Kartensatz (atlas/qgis/basis/). Für die Bodennutzung existiert die CORINE-Pipeline (atlas/geodaten/rumaenien-nutzung.rb).

Roadmap Reiseführer ⋅ Fassung 1.0Seite 2 von 4

Roadmap Reiseführer ⋅ Fassung 1.02–3 Datenmodell & Bahn

2Datenmodell: das GeoPackage

Deutsche Layer- und Feldnamen sind der Contract — dieselbe Konvention wie in den Atlas-Datenmodulen; wer ein Feld umbenennt, bricht den Build, nicht die Reise. Auswahlfelder werden in QGIS als ValueMap angelegt, damit QField sie als Auswahlliste zeigt; URL-Felder sind aus dem Formular heraus antippbar.

LayerGeometryKernfelder

poi_draculaPointname, beschreibung, foto, url, bahnhof_id

poi_deltaPointname, art {anleger, beobachtung, ort}, url

naturparksPolygonname, schutzstatus, url

touren_betonLine ⋅ Pointtour_id, station_nr, name, baujahr, architekt, foto

routen_autoLineref, klasse, fahrzeit_min (vorgerechnet)

bahnhoefePointname, cfr_id, deep_link

hanfPointname, art {anbau, verarbeitung}, url

nutzung_*Polygonneun CORINE-Klassen aus der Pipeline, read-only

Alle Layer sind read-only — der Reiseführer konsumiert. Die Basemap reist als MBTiles mit, auf Rumänien beschnitten und gedämpft; Zoomstufen 6–12 landesweit plus 13–14 für das Banat und Bukarest halten das Paket unter einem Gigabyte.

3Bahn: GTFS-Endpoint und Deep-Links

Die eigene API bleibt bewusst klein — zwei statische Endpoints, wöchentlich per Cron-Job neu gebaut. QField braucht davon nichts zur Laufzeit; die Pipeline schreibt die Ergebnisse beim Build als Felder ins GeoPackage.

GET /gtfs.zip        Fahrplan CFR Călători, GTFS statisch
GET /stations.json   [{ cfr_id, name, lat, lon }]

deep_link (Feld) = "https://mersultrenurilor.infofer.ro/ro-RO/
                    Itineraries?From={ort}&To={ziel}"

Roadmap Reiseführer ⋅ Fassung 1.0Seite 3 von 4

Roadmap Reiseführer ⋅ Fassung 1.04–5 Meilensteine & Risiken

4Meilensteine: vier Wochen bis zum Praxistest

WocheErgebnis (jeweils prüfbar)

1GeoPackage-Schema angelegt, Signaturen als .qml übersetzt, CORINE-Pipeline gelaufen — ein QGIS-Projekt, das aussieht wie Blatt 18.

2–3POI-Erfassung (Banat dicht, Rest gerüstweise), Touren Bukarest, GTFS-Endpoint + Deep-Link-Felder, Deployment des QFieldSync-Pakets auf die eigene Cloud, zwei Testgeräte.

4Praxistest auf Reise (Banat), Rücksync der Fotos/Notizen vom Testgerät, kurzer Befund: was fehlt, was nervt, was fliegt. Danach Go/No-Go für den Web-Begleiter.

5Risiken und offene Punkte

GTFS-Quelle: CFR Călători liefert kein offizielles GTFS — der Feed muss aus Fahrplandaten gebaut werden. Aufwand unklar, deshalb liegt er in der eigenen API und nicht im kritischen Pfad.
MBTiles-Größe: Zoom 13–14 nur für Banat und Bukarest; wächst der Wunsch nach Detail landesweit, braucht es einen Kachel-Rebuild (halber Tag Rechenzeit).
Fonts auf dem Gerät: die Branchenkreise beschriften per FontMarker mit Noto Sans Mono — die Schrift muss ins QFieldSync-Paket, sonst fällt Android auf Roboto zurück. (Die Tiegel- und Grundriss-Marker liegen inzwischen als SVG im Kartensatz; Woche 1 wird dadurch kürzer.)
Deep-Links: infofer.ro kann URL-Parameter ändern; das Feld liegt deshalb in den Daten, nicht im Stil — ein Fix ist ein Sync, kein Release.
QFieldCloud als Single Point of Failure: fällt die Instanz unterwegs aus, übernimmt Syncthing — und das ist fast der schönere Weg: zwei Geräte tauschen den Projektordner direkt im Hotel-WLAN, kein Server, kein Account, keine Cloud dazwischen. Einmal QR-Code scannen, ab dann syncen sie sich von allein. Einzige Regel (KISS): Syncthing synct ganze Dateien, nicht Attribute — also verteilen, nicht gleichzeitig editieren.

Bezüge

[1]Entscheidungs-Präsentation: praesentationen/Reiseplaner-Vorschlag.dc.html [2]Wireframes Hauptscreen und Themenwahl: praesentationen/Wireframe-A-Chips.dc.html ⋅ -B-Tabs ⋅ -C-Split [3]Signaturenkatalog und QGIS-Kartensatz: atlas/signaturen.js ⋅ atlas/qgis/ [4]CORINE-Pipeline: atlas/geodaten/rumaenien-nutzung.rb ⋅ Glossar: atlas/GLOSSAR.md

Kolophon

Gesetzt in Gentium Plus und Noto Sans Mono, Arbeitssystem EPSG:32635. Weltzeit nach π + π² + 4π³ ≈ 137,036.

Jan Paki ⋅ jan ⋆_ℏ sternprodukt.deSeite 4 von 4