Wie soll ich PostGIS-Rasterdaten mit unterschiedlichen Projektionen verwalten?

Ich muss archäologische geophysikalische Daten speichern und verwalten , die als rechteckige Anordnung von Proben gesammelt werden - ein Rasterbild.

• Jedes Raster enthält normalerweise 20x20- oder 30x30-Gleitkomma-Samples, die normalerweise in Intervallen von 1 m abgetastet werden.
• Eine Umfrage besteht aus einem oder mehreren dieser Bilder an einem bestimmten Ort.
• Es ist möglich, dass zwei verschiedene Erhebungen in verschiedenen Ländern oder Gebieten mit unterschiedlichen Projektionen stattfinden, aber jede Erhebung verwendet nur eine einzige Projektion.
• Es ist unwahrscheinlich, dass sie zusammen angezeigt werden. Jede Umfrage wird normalerweise für sich durchgeführt.
• Auf die Daten wird nur über ein benutzerdefiniertes Front-End zugegriffen, sodass keine Benutzer die direkte Kontrolle über sie psqloder ähnliches erhalten.
• Jede Probe muss so gespeichert werden, wie sie gesammelt wurde, daher kann ich sie nicht in ein allgemeines CRS wie Web Mercator projizieren, da eine Probe möglicherweise mehr oder weniger Fläche als in der ursprünglichen Projektion abdeckt und eine Analyse durchgeführt werden muss auf die Daten.

Wie soll ich die Daten am besten in einer PostGIS Raster-Datenbank speichern? Die Optionen, die ich mir ausgedacht habe, sind:

1. Ignorieren Sie SRID-Einschränkungen und speichern Sie alle Daten in einer Tabelle. Schreiben Sie meinen Front-End-Code, um die Daten auf konsistente Weise zu bearbeiten.
2. Speichern Sie alle Daten in einer Tabelle und schreiben Sie die SRID-Einschränkung als Verbindung aus SRID und Umfrage-ID neu.
3. Erstellen Sie durch Tabellenvererbung eine neue Tabelle für jede neue SRID.
4. Erstellen Sie durch Tabellenvererbung für jede Umfrage eine neue Tabelle.

1 und 2 brechen einige der netten automatisierten Teile von PostGIS, werden aber ansonsten im Front-End-Code versteckt. Aber Abfragen werden wahrscheinlich etwas länger dauern.

3 und 4 könnten zu einer Explosion von Tabellen führen, die das Verwalten von FK-Einschränkungen usw. erschweren würde.

In der Praxis liegt die Anzahl der Raster pro Umfrage zwischen 1 und 100 oder mehr, und die Anzahl der Umfragen wird wahrscheinlich Hunderte betragen. Die Anzahl der unterschiedlichen Projektionen dürfte jedoch sehr gering bleiben, was 3 begünstigt.

Ich habe über Ihre Frage nachgedacht und bin schließlich zu dem Schluss gekommen, dass ich jede Umfrage in einer eigenen Datenbank speichern würde .

HINWEIS : Mit Datenbank meine ich eine Datenbank, die in einem einzelnen Postgres-Datenbankcluster gemäß der hier angegebenen Postgres-Terminologie erstellt wurde , nicht einen vollständig separaten Postgres-Prozess mit eigenen Benutzern, Vorlage1 usw.

Dies mag zwar übertrieben klingen, bietet jedoch mehrere Vorteile:

• Verwaltbarkeit: Jede Umfrage verfügt nur über eine Rastertabelle mit srid, mit der Sie die Postgis-Standards für die Datenverwaltung so weit wie möglich einhalten können (dh keine Probleme mit der Tabelle raster_columns oder FKs oder Einschränkungen. Alle Postgis-Funktionen funktionieren weiterhin wie erwartet).

• Einfachheit: Solange Sie eine kohärente Benennungsstrategie anwenden und durchsetzen, wie z. B.: Rufen Sie jede Datenbank als srvy_- Namen auf und verwenden Sie dann denselben Namen (dh Überwachungsdaten ) für alle Rastertabellen und -spalten . Wenn Sie so interessiert sind (ich weiß, ich würde ;-)), können Sie jeder Datenbank auch eine Metadatentabelle hinzufügen, die beschreibt, welche Art von Daten in dieser Datenbank gespeichert sind, wann sie zuletzt aktualisiert wurden und so weiter. Das Erstellen von Skripten / Abfragen einer Datenbankstruktur mit einer solchen kohärenten Benennung wäre einfach (und angenehm).

• Es funktioniert gemäß Ihren Anforderungen, solange jede Umfrage ihren eigenen Srid verwendet

• Skalierbarkeit: Skaliert, weil Sie Datenbanken (durch Zuweisen auf verschiedenen Tablespaces ) auf verschiedene Spindeln (oder Festplatten, Pools, Lun, je nach Speicheranbieter) verschieben können, damit E / A parallelisiert werden können. Es wäre viel schwieriger, Tabellen aus derselben Datenbank auf verschiedene Festplatten zu verschieben

• Sicherheit: Sie können verschiedenen Umfragen unterschiedliche Berechtigungen erteilen, indem Sie die Datenbanksicherheit ausnutzen (als zusätzliche Ebene über der Anwendung).

• getestet: Es liegen Berichte von Postgres gewesen Tausende von Datenbanken auf einer einzigen Instanz, siehe Handhabung dieser für eine Referenz

• [dies muss getestet werden, ich weiß, dass es für Geometrien funktioniert, weiß nicht für Raster] Sie können immer noch alle Raster gleichzeitig abfragen (und transformieren), indem Sie Ansichten wie die folgenden erstellen:

create or replace view v_all_surveys_as_wgs84 as select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number1.rasterdata union all select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number2.rasterdata [...]

Ein mögliches Argument dagegen ist, dass dieses Setup komplex ist, aber ich würde zurück argumentieren, dass es stattdessen sehr einfach zu replizieren ist, sobald die erste Datenbank eingerichtet wurde, und dass es dann vollständig in Skripten verwaltet werden kann, wenn die richtige Namensrichtlinie eingerichtet ist.