Eigenständige, kleine Skripte, um die lokal vorliegenden CO2-Map-Inputs (MaStR,
Shapefiles, Kapazitäts-Parquets, Demand-Regionalisierungsfaktoren,
Technologie-Zuordnungstabellen) einmalig in ein eigenes Postgres-Schema
(cosema_inputs) auf dem OEDS-Server hochzuladen. Bewusst nicht Teil des
open-energy-data-server/co2map-Repos — eigenständig lauffähig, keine
Abhängigkeit von dessen Code.
Wetter-Cutouts (NetCDF) sind nicht dabei — die bleiben vorerst lokal (Entscheidung Stand 2026-08-21).
pip install -r requirements.txt
cp .env.example .env
Dann .env ausfüllen:
DB_HOST,DB_PORT,DB_PASSWORD(Werte beim Server-Admin erfragen). Produktion und Staging sind getrennte Datenbanken auf unterschiedlichen Ports — der Port muss zur gewünschten Umgebung passen.- die lokalen Quellpfade für die Skripte, die du tatsächlich laufen lassen willst (leer lassen, was du nicht brauchst)
Jedes Skript ist unabhängig lauffähig, in beliebiger Reihenfolge:
python transfer_mastr.py # braucht MASTR_SQLITE_PATH
python transfer_shapefiles.py # braucht SHAPEFILES_DIR
python transfer_capacities.py # braucht CAPACITIES_DIR
python transfer_demand_reg_factors.py # braucht DEMAND_REG_DATA_DIR
python transfer_generation_data.py # braucht GENERATION_DATA_DIR
transfer_mastr.py ist der einzige, der länger dauern kann (~13 GB, läuft
tabellenweise + gechunkt, um nicht alles auf einmal in den Speicher zu laden).
Alle anderen sind klein genug für einen einzigen Durchlauf.
Alle Skripte legen das Zielschema (cosema_inputs, per TARGET_SCHEMA in
.env änderbar) automatisch an, falls es noch nicht existiert, und
überschreiben ihre jeweilige(n) Zieltabelle(n) bei erneutem Lauf
(if_exists="replace") — außer transfer_mastr.py, das pro Quelltabelle
ebenfalls komplett ersetzt, aber intern in Chunks schreibt.
Beim Start loggt jedes Skript die Zeile Target DB: host:port/db, schema '…'
(ohne Passwort), damit klar ist, in welche Datenbank geschrieben wird. Der
Verbindungsaufbau bricht nach 30 s mit einem Fehler ab, statt endlos zu
hängen; transfer_mastr.py lässt sich danach einfach neu starten und macht
dort weiter, wo es aufgehört hat.
Langfristig sollen die Transfers regelmäßig und serverseitig über Prefect laufen. Vorbereitet sind:
flows.py: dünne@flow-Wrapper um diemain()-Funktionen vontransfer_mastr.py,transfer_capacities.pyundtransfer_demand_reg_factors.py(die Skripte selbst bleiben unverändert und laufen weiter einzeln, sie brauchen Prefect nicht).prefect.yaml: drei Deployments auf dem Work-Poollocal-pool; der Worker klont dieses Repo und installiertrequirements.txt. Noch ohne Zeitpläne.
Stand: noch nichts deployt. Auf dem Server gibt es die lokalen Quelldateien nicht, die Flows müssen ihre Daten dort direkt aus der Originalquelle beziehen, bevor ein Deploy sinnvoll ist. Details und Fahrplan: PREFECT_PLAN.md.
Für die Flows lokal zusätzlich (gleiche Version wie auf dem Server):
pip install prefect==3.6.17
MASTR_SQLITE_PATH: der Standardpfad vonopen-mastrist~/.open-MaStR/data/sqlite/open-mastr.db(auf Windows bestätigt); bei abweichender Installation den echten Pfad in.enveintragen.transfer_shapefiles.py: die Dateiliste (FILES-Dict) geht von den Pfaden ausco2map/config.yamlaus (states.geojson,plz/OSM_PLZ.shp) — anpassen, falls die lokale Struktur abweicht.