Eine Geo-Koordinate hinein, ein konsolidiertes Risikoprofil heraus. Diese Case Study zeigt, Wie wir bei osnabyte fragmentierte Behördendaten der DACH-Region zu einer auditierbaren API gebündelt haben.
Wer in Deutschland, Österreich oder der Schweiz eine Immobilien-Risikoeinschätzung benötigt, landet bei einer Recherche schnell in einem Flickenteppich aus Bundes- und Länderportalen. Hochwassergefahrenkarten liegen bei den Landesumweltämtern, Wetterdaten beim DWD, Geobasisdaten beim BKG. Jede Behörde liefert in einem eigenen Schema, mit eigenen Koordinatensystemen, eigenen Rate-Limits und teilweise nur als statisches PDF oder Web-Viewer.
Für Versicherer, Asset-Manager, PropTech-Plattformen und Bewertungsdienstleister bedeutet das: Wer ein einziges Risikoprofil pro Adresse zusammensetzen will, integriert dutzende Endpunkte, harmonisiert Geometrien, schreibt Datenpipelines, hält Skalen aktuell und führt einen permanenten Rückwärtskompatibilitäts-Tanz mit jedem Update der Behörden. Ein API-first-Anbieter, der diese Arbeit zentral übernimmt und Daten DSGVO-konform sowie audit-fähig ausliefert, fehlte im deutschsprachigen Markt.
Genau diese Marktlücke war der Anlass für Terrafakt. Wir wollten herausfinden, ob sich der Aufwand für Konsumenten dieser Daten so weit reduzieren lässt, dass ein einziger HTTP-Request mit einer Geo-Koordinate ein verlässliches, maschinenlesbares Risikoprofil zurückgibt – inklusive Provenance pro Datenpunkt.
Das Designprinzip von Terrafakt ist auf ein einzelnes Ziel ausgerichtet: maximale Reduktion von Integrations-Reibung auf der Konsumentenseite. Konkret bedeutet das, dass jede Antwort ein deterministisches JSON-Dokument ist, in dem jeder einzelne Datenpunkt mit seiner Quelle, dem Erhebungsstand und dem methodischen Hintergrund versehen ist. Provenance ist kein Annex, sondern Pflichtfeld pro Wert.
API-first heißt für uns auch, dass DSGVO-Konformität nicht nachträglich angeflanscht wird. Personenbezogene oder quasi-personenbezogene Datenflüsse, etwa IP-Adressen aus API-Aufrufen, sind von Beginn an pseudonymisiert. Auskunfts- und Löschrechte nach Artikel 15 und 17 DSGVO sind nicht organisatorische Prozesse, sondern ganz konkret eigene Endpunkte der API. Das macht das System auditierbar und schließt eine ganze Klasse an Compliance-Risiken bereits in der Architekturentscheidung aus.
Der eigentliche Engineering-Kern dieses Projekts liegt in der Geometrieverarbeitung. Behördenkarten wie die Hochwassergefahrenflächen des LANUV in Nordrhein-Westfalen liegen typischerweise als sehr feingranulare Polygone vor. Skaliert man das auf alle Bundesländer und Risikoebenen, entstehen Datensätze mit Millionen Einzelgeometrien. Performante Punkt-in-Polygon-Abfragen auf diesem Volumen sind kein triviales Problem – und genau dort war für uns auch die spannendste Lernkurve.
Wir haben uns für PostGIS auf einem dedizierten PostgreSQL-Cluster entschieden und alle Geometrien konsequent in EPSG:3035 gespeichert. Die Projektion Lambert Azimuthal Equal Area Europe ist flächentreu, in der gesamten DACH-Region in Metern rechenbar und vermeidet die Verzerrungen, die bei reinen WGS84-Operationen auf größeren Polygonen entstehen. Indexiert wird über GiST mit zusätzlichen Cluster-Strategien für die häufigsten Lookup-Patterns. Ein Beispiel für die Datenarchitektur lässt sich auf der Beispielregion Nordrhein-Westfalen nachvollziehen, anhand derer wir das Schema initial validiert haben.
Auf dieser Basis erreichen wir Sub-100ms p95 für Spatial-Lookups inklusive Provenance-Joins. Das ist gemessen, nicht extrapoliert: p95 referenziert das 95. Perzentil der gemessenen End-to-End-Antwortzeiten unter realistischer Last, nicht die Median-Response auf einem leeren System. Das Ziel war bewusst aggressiv gewählt, weil Risikodaten meistens nicht isoliert abgefragt werden, sondern in Backend-Pipelines hinter anderen Aufrufen hängen.
Zur Story-Ebene gehört: Geo-Daten waren für uns als osnabyte vor Terrafakt kein tägliches Brot. Das Projekt war damit gleichzeitig technische Weiterbildung mit ernstem Use-Case – und ist heute der Hauptgrund, warum wir Kunden bei räumlich anspruchsvollen Backend-Themen mit echtem Praxis-Hintergrund beraten können.
Der Backend-Stack ist bewusst schlank gehalten: Next.js 16 als Framework, Prisma 7 als ORM, PostgreSQL mit PostGIS als primärer Datenspeicher. Auf der Schnittstelle setzen wir auf eine vollständige OpenAPI-Spezifikation, die nicht nur als Generator für SDKs dient, sondern als Single Source of Truth für das Vertragsmodell zwischen API und Konsumenten. Ein eingebettetes Scalar-Playground macht die Spec direkt ausprobierbar, ohne dass Entwickler vorher Tokens beziehen oder Postman-Collections importieren müssen.
Fehlerantworten folgen konsequent RFC 7807. Jedes Problem-Detail hat einen stabilen Typ, eine maschinenlesbare Beschreibung und Kontextfelder, die Aufrufer ohne Stringparsing auswerten können. IP-Adressen aus API-Calls werden mit HMAC-SHA256 unter Verwendung eines rotierbaren Peppers pseudonymisiert – so bleibt Rate-Limiting und Missbrauchserkennung möglich, ohne identifizierbare Adressen dauerhaft zu speichern. Auskunft nach Artikel 15 DSGVO und Löschung nach Artikel 17 DSGVO sind in der API als reguläre Endpunkte umgesetzt und damit automatisierbar.
Bemerkenswert ist auch das Tempo: Vom ersten Commit bis zur tragfähigen Architektur mit gemessenen Performance-Werten vergingen weniger als einen Monat Entwicklungszeit. Das war nur möglich, weil wir von Beginn an klare Designprinzipien hatten und in jeder Komponente lieber eine bewährte Lösung gewählt haben als einen Hype-Stack.
Das Konzept hinter Terrafakt umfasst deutlich mehr Risikoebenen, als ein einzelnes Datenmodell jemals abschließend abbilden könnte. Vorgesehen sind weitere fluviale und pluviale Hochwasserdaten, Starkregen-Indizes auf Basis von Niederschlagsstatistiken, seismische Gefährdung, Wasserschutzgebiete, Radonpotenzial und Wind- sowie Schneelasten aus den einschlägigen Normwerken. Ergänzend ist die Integration von Bodenrichtwerten und langfristigen Klimaprojektionen Teil des konzeptionellen Scopes.
Geplant ist außerdem, das Datenmodell um stärker normalisierte Aggregat-Indizes zu erweitern, die mehrere physikalische Risikoebenen zu einem Vergleichswert verdichten. Solche Aggregate sind in der Versicherungswelt etabliert, fehlen aber in einer offenen, auditierbaren Form. Den aktuellen Datenscope und die geplanten Erweiterungen dokumentieren wir fortlaufend in der Risikodaten-API von Terrafakt.
Wichtig ist uns dabei, dass jede Erweiterung dem Provenance- und Audit-Prinzip folgt: Jeder neue Wert kommt mit Quelle, Stand und methodischer Beschreibung in den Response, oder er wird nicht ausgeliefert.
Welche Indexstrategien, Projektionswahl und Geometrie-Preprocessing-Schritte einen Punkt-in-Polygon-Lookup von Sekunden auf Millisekunden bringen – dieses Wissen fließt direkt in jede Backend-Beratung mit räumlicher Komponente.
Saubere Trennung von Rohdaten-Import, Normalisierung und Provenance-Zuordnung skaliert in jedem Projekt, in dem externe Datenquellen mit unterschiedlicher Update-Frequenz eingebunden werden müssen.
Provenance pro Datenpunkt, RFC-7807-Fehlerformat und eine vollständige OpenAPI-Spec als Vertrag sind heute unsere Standardelemente für ernstgemeinte B2B-Schnittstellen.
Pseudonymisierung und Auskunfts- bzw. Löschungs-Endpunkte von Anfang an einzuplanen ist günstiger und sicherer, als Compliance später als Add-on einzubauen. Diesen Ansatz empfehlen wir Kunden inzwischen konsequent.
Wenn auch Sie hinter einem fragmentierten Markt eine API-Lücke sehen, sprechen wir gerne darüber. Wir denken Architektur, Performance und Compliance von Anfang an zusammen.