Eine schnelle Möglichkeit, die vollständige geokodierte nationale Adressdatei Australiens (GNAF) und die australischen Verwaltungsgrenzen vereinfacht und sofort als Referenzdaten für die Geokodierung, Analyse, Visualisierung und Aggregation in Postgres zu laden.
Schauen Sie sich diese Einführungsfolien (PDF) sowie die Seite data.gov.au an.
Führen Sie das Python-Skript „load-gnaf“ aus und erstellen Sie die Datenbank in einem einzigen Schritt selbst
Ziehen Sie die Datenbank vom Docker Hub und führen Sie sie in einem Container aus
Laden Sie die GNAF- und/oder Admin Bdys Postgres-Dump-Dateien herunter und stellen Sie sie in Ihrer Postgres 14+-Datenbank wieder her
Verwenden oder laden Sie Geoparquet und Parquet Files in S3 für Ihre Daten- und Analyse-Workflows herunter; entweder in AWS oder Ihrer eigenen Plattform.
Die Ausführung des Python-Skripts dauert 30–120 Minuten auf einem Postgres-Server, der so konfiguriert ist, dass er den verfügbaren RAM nutzt.
Sie können die GDA94- oder GDA2020-Version der Daten verarbeiten. Stellen Sie lediglich sicher, dass Sie dieselbe Version sowohl für GNAF als auch für die Verwaltungsgrenzen herunterladen. Wenn Sie nicht wissen, was GDA94 oder GDA2020 ist, laden Sie die GDA94-Versionen herunter (zu Ihrer Information: es handelt sich um unterschiedliche Koordinatensysteme).
Um eine gute Ladezeit zu erreichen, müssen Sie Ihren Postgres-Server auf Leistung konfigurieren. Hier gibt es eine gute Anleitung, in der darauf hingewiesen wird, dass es schon ein paar Jahre alt ist und einige der Speicherparameter verbessert werden können, wenn Sie über den RAM verfügen.
Postgres 14.x und höher mit PostGIS 3.2+
Fügen Sie das Postgres-bin-Verzeichnis zu Ihrem Systempfad hinzu
Python 3.6+ mit Psycopg 3.x
Laden Sie Geoscape GNAF von data.gov.au herunter (GDA94 oder GDA2020)
Laden Sie Geoscape Administrative Boundaries von data.gov.au herunter ( laden Sie die ESRI Shapefile-Version (GDA94 oder GDA2020) herunter )
Entpacken Sie GNAF in ein Verzeichnis auf Ihrem Postgres-Server
Entpacken Sie Admin Bdys in ein lokales Verzeichnis
Ändern Sie die Sicherheit dieser Verzeichnisse, um Postgres Lesezugriff zu gewähren
Erstellen Sie die Zieldatenbank (falls erforderlich)
Fügen Sie PostGIS zur Datenbank hinzu (falls erforderlich), indem Sie die folgende SQL ausführen: CREATE EXTENSION postgis
Überprüfen Sie die verfügbaren und erforderlichen Argumente, indem Sie „load-gnaf.py“ mit dem Argument -h ausführen (siehe Befehlszeilenbeispiele unten).
Führen Sie das Skript aus, kommen Sie in 30–120 Minuten wieder und genießen Sie es!
Das Verhalten von gnaf-loader kann durch die Angabe verschiedener Befehlszeilenoptionen für das Skript gesteuert werden. Unterstützte Argumente sind:
--gnaf-tables-path gibt den Pfad zu den extrahierten GNAF-PSV-Dateien an. Auf dieses Verzeichnis muss der Postgres-Server zugreifen können , und der entsprechende lokale Pfad für den Server zu diesem Verzeichnis muss möglicherweise über das Argument „ local-server-dir festgelegt werden
--local-server-dir gibt den lokalen Pfad auf dem Postgres-Server an, der gnaf-tables-path entspricht. Wenn der Server lokal läuft, kann dieses Argument weggelassen werden.
--admin-bdys-path gibt den Pfad zu den extrahierten Shapefile-Administratorgrenzdateien an. Im Gegensatz zu gnaf-tables-path muss dieser Pfad nicht unbedingt für den Remote-Postgres-Server zugänglich sein.
--pghost der Hostname für den Postgres-Server. Dies ist standardmäßig die Umgebungsvariable PGHOST , sofern diese festgelegt ist, andernfalls lautet der Standardwert localhost .
--pgport die Portnummer für den Postgres-Server. Standardmäßig wird die Umgebungsvariable PGPORT verwendet, sofern diese festgelegt ist, andernfalls 5432 .
--pgdb der Datenbankname für den Postgres-Server. Standardmäßig wird die Umgebungsvariable PGDATABASE verwendet, falls festgelegt, andernfalls geoscape .
--pguser der Benutzername für den Zugriff auf den Postgres-Server. Standardmäßig wird die Umgebungsvariable PGUSER verwendet, sofern diese festgelegt ist, andernfalls postgres .
--pgpassword Passwort für den Zugriff auf den Postgres-Server. Standardmäßig wird die Umgebungsvariable PGPASSWORD verwendet, sofern diese festgelegt ist, andernfalls password .
--srid Legt das Koordinatensystem der Eingabedaten fest. Gültige Werte sind 4283 (Standard: GDA94 Breite/Länge) und 7844 (GDA2020 Breite/Länge).
--geoscape-version Geoscape-Versionsnummer im Format JJJJMM. Standardmäßig werden das aktuelle Jahr und der letzte Veröffentlichungsmonat verwendet. zB 202408 .
--previous-geoscape-version Versionsnummer der vorherigen Geoscape-Version als JJJJMM; Wird für den QS-Vergleich verwendet. zB 202405 .
--raw-gnaf-schema Schemaname zum Speichern von Roh-GNAF-Tabellen. Standardmäßig ist raw_gnaf_ .
--raw-admin-schema Schemaname, in dem rohe Admin-Grenztabellen gespeichert werden sollen. Der Standardwert ist raw_admin_bdys_ .
--gnaf-schema Name des Zielschemas, in dem die endgültigen GNAF-Tabellen gespeichert werden sollen. Der Standardwert ist gnaf_ .
--admin-schema Name des Zielschemas, in dem die endgültigen Admin-Grenztabellen gespeichert werden sollen. Standardmäßig ist admin_bdys_ .
--previous-gnaf-schema Schema mit der vorherigen Version der GNAF-Tabellen in. Standardmäßig ist gnaf_ > .
--previous-admin-schema Schema mit vorheriger Version der Admin-Grenztabellen in. Standardmäßig ist admin_bdys_ .
--states durch Leerzeichen getrennte Liste der zu ladenden Zustände, z. B. --states VIC TAS . Standardmäßig werden alle Zustände geladen.
--prevacuum erzwingt das Vakuumieren der Datenbank nach dem Löschen von Tabellen. Die Standardeinstellung ist „Aus“, und die Angabe dieser Option verlangsamt den Importvorgang.
--raw-fk erstellt sowohl Primär- als auch Fremdschlüssel für die rohen GNAF-Tabellen. Die Standardeinstellung ist deaktiviert und verlangsamt den Importvorgang, sofern angegeben. Verwenden Sie diese Option, wenn Sie beabsichtigen, die rohen GNAF-Tabellen nicht nur als temporären Importschritt zu verwenden. Beachten Sie, dass für die endgültig verarbeiteten Tabellen immer die entsprechenden Primär- und Fremdschlüssel festgelegt sind.
--raw-unlogged erstellt nicht protokollierte Roh-GNAF-Tabellen und beschleunigt so den Import. Die Standardeinstellung ist „Aus“. Geben Sie diese Option nur an, wenn Ihnen die Rohdatentabellen nach dem Import egal sind – diese gehen bei einem Serverabsturz verloren!
--max-processes gibt die maximale Anzahl paralleler Prozesse an, die für das Laden der Daten verwendet werden sollen. Stellen Sie dies auf die Anzahl der Kerne auf dem Postgres-Server minus 2 ein, begrenzen Sie es jedoch auf 12, wenn mehr als 16 Kerne vorhanden sind – über 12 hinaus gibt es nur minimale Vorteile. Der Standardwert ist 4.
--no-boundary-tag Markieren Sie NICHT alle Adressen mit einigen der wichtigsten Admin-Grenz-IDs zum Erstellen von Aggregaten und Choroplethenkarten.
Lokaler Postgres-Server: python load-gnaf.py --gnaf-tables-path="C:tempgeoscape_202408G-NAF" --admin-bdys-path="C:tempgeoscape_202408Administrative Boundaries" Lädt die GNAF-Tabellen auf einen lokal laufenden Postgres-Server. GNAF-Archive wurden in den Ordner C:tempgeoscape_202408G-NAF extrahiert, und Administratorgrenzen wurden in den Ordner C:tempgeoscape_202408Administrative Boundaries extrahiert.
Remote-Postgres-Server: python load-gnaf.py --gnaf-tables-path="svrsharedgnaf" --local-server-dir="f:sharedgnaf" --admin-bdys-path="c:tempunzippedAdminBounds_ESRI" Lädt die GNAF-Tabellen, die in den freigegebenen Ordner svrsharedgnaf extrahiert wurden. Dieser freigegebene Ordner entspricht dem lokalen Ordner f:sharedgnaf auf dem Postgres-Server. Admin-Grenzen wurden in den Ordner c:tempunzippedAdminBounds_ESRI extrahiert.
Nur ausgewählte Bundesstaaten werden geladen: python load-gnaf.py --states VIC TAS NT ... Lädt nur die Daten für Victoria, Tasmanien und Northern Territory
Sie können die Admin-Grenzen ohne GNAF laden. Gehen Sie dazu wie folgt vor: Kommentieren Sie die Schritte 1, 3 und 4 in def main aus.
Hinweis: Sie können GNAF nicht ohne die Admin-Bdys laden, da Abhängigkeiten erforderlich sind, um Melbourne aufzuteilen und nicht grenzüberschreitende locality_pids für Adressen zu korrigieren.
Wenn Sie die aus diesem Prozess resultierenden Daten verwenden, müssen Sie im Rahmen der Open-Data-Lizenzanforderungen die Quellennachweisanforderungen auf den data.gov.au-Seiten für GNAF und Admin Bdys einhalten.
Die Skripte löschen ALLE TABELLEN mithilfe von CASCADE in den GNAF- und Admin-Bdy-Schemas und erstellen sie dann neu. Das bedeutet, dass Sie IHRE ANSICHTEN VERLIEREN, wenn Sie welche erstellt haben! Wenn Sie die vorhandenen Daten beibehalten möchten, müssen Sie die Schemanamen im Skript ändern oder eine andere Datenbank verwenden
Alle rohen GNAF-Tabellen können UNLOGGED erstellt werden, um das Laden der Daten zu beschleunigen. Dies macht sie UNWIEDERHERSTELLBAR, wenn Ihre Datenbank beschädigt ist. Sie können diese Skripte erneut ausführen, um sie neu zu erstellen. Wenn Sie der Meinung sind, dass das in Ordnung klingt, setzen Sie das Flag „unlogged_tables“ auf „True“, um den Ladevorgang etwas zu beschleunigen
Die Grenzmarkierung (standardmäßig aktiviert) verlängert den Vorgang um 15–60 Minuten, wenn Sie PostGIS 2.2+ verwenden. Wenn Sie PostGIS 2.1 oder niedriger haben, kann es STUNDEN dauern, da die Grenztabellen nicht optimiert werden können!
Sie können zwar auswählen, in welche 4 Schemata die Daten geladen werden sollen, ich habe jedoch nicht jede Permutation einer Qualitätssicherung unterzogen. Bleiben Sie bei den Standardeinstellungen, wenn Sie nur über begrenzte Postgres-Erfahrung verfügen
Wenn Sie das Python-Skript nicht auf dem Postgres-Server ausführen, benötigen Sie Zugriff auf einen Netzwerkpfad zu den GNAF-Dateien auf dem Datenbankserver (um die Liste der zu verarbeitenden Dateien zu erstellen). Die Alternative besteht darin, eine lokale Kopie der Rohdateien zu haben
Das SQL-Skript „Tabellen erstellen“ fügt die PostGIS-Erweiterung zur Datenbank im öffentlichen Schema hinzu. Sie müssen sie nicht zu Ihrer Datenbank hinzufügen
Es besteht die Möglichkeit, die Datenbank beim Start zu VAKUUMEN, nachdem die vorhandenen GNAF/Admin Bdy-Tabellen gelöscht wurden – dies hat außer wiederholten Tests keine wirkliche Wirkung. (Ich war zu faul, es aus dem Code zu entfernen, da das eine Neunummerierung aller SQL-Dateien bedeutete und ich jetzt gerne ins Bett gehen würde)
GNAF und die Admin-Grenzen können in Postgres in einem Image auf Docker Hub verwendet werden.
Ziehen Sie in Ihrer Docker-Umgebung das Image mit docker pull minus34/gnafloader:latest
Ausführen mit docker run --publish=5433:5432 minus34/gnafloader:latest
Greifen Sie über Port 5433 auf Postgres im Container zu. Der Standard-Login lautet: Benutzer: postgres , Passwort: password
Hinweis: Das komprimierte Docker-Image ist 8 GB groß, das unkomprimierte 25 GB
WARNUNG: Das Standard-Postgres-Superuser-Passwort ist unsicher und sollte wie folgt geändert werden:
ALTER USER postgres PASSWORD '
Laden Sie Postgres-Dump-Dateien herunter und stellen Sie sie in Ihrer Datenbank wieder her.
Sollte 15-60 Minuten dauern.
Postgres 14+ mit PostGIS 3.0+
Kenntnisse der Postgres pg_restore-Parameter
Laden Sie die GNAF-Dump-Datei oder die GNAF GDA2020-Dump-Datei herunter (~2,0 GB).
Laden Sie die Admin Bdys-Dump-Datei oder die Admin Bdys GDA2020-Dump-Datei herunter (~2,8 GB).
Bearbeiten Sie das Skript „restore-gnaf-admin-bdys.bat“ oder „.sh“ im Ordner „supporting-files“ für die Namen Ihrer Dump-Dateien, Datenbankparameter und den Speicherort von pg_restore
Führen Sie das Skript aus, kommen Sie in 15–60 Minuten wieder und genießen Sie es!
Geoparquet-Versionen der räumlichen Tabellen sowie Parkett-Versionen der nicht räumlichen Tabellen befinden sich in einem öffentlichen S3-Bucket zur direkten Verwendung in einer Anwendung oder einem Dienst. Sie können auch über die AWS CLI heruntergeladen werden.
Geometrien haben WGS84-Breiten-/Längenkoordinaten (SRID/EPSG:4326). Eine Beispielabfrage zur Analyse der Daten mit Apache Sedona, der räumlichen Erweiterung von Apache Spark, befindet sich im spark -Ordner.
Die Dateien sind hier: s3://minus34.com/opendata/geoscape-202408/geoparquet/
Alle Datensätze auflisten: aws s3 ls s3://minus34.com/opendata/geoscape-202408/geoparquet/
Kopieren Sie alle Datensätze: aws s3 sync s3://minus34.com/opendata/geoscape-202408/geoparquet/
Integriert oder entwickelt unter Verwendung von G-NAF © Geoscape Australia, lizenziert vom Commonwealth of Australia unter der Endbenutzer-Lizenzvereinbarung „Open Geo-coded National Address File (G-NAF)“.
Eingebunden oder unter Verwendung administrativer Grenzen entwickelt © Geoscape Australia, lizenziert vom Commonwealth of Australia unter der Creative Commons Attribution 4.0 International-Lizenz (CC BY 4.0).
GNAF und die Admin Bdys wurden angepasst, um einige der bekannten, geringfügigen Einschränkungen bei den Daten zu beseitigen. Die bemerkenswertesten sind:
Alle Adressen verweisen auf einen Ort mit Ortsangaben, der eine Grenze hat. Für die kleine Anzahl von Adressen, die nicht im Roh-GNAF enthalten sind, wurde die locality_pid in eine im Amtsblatt angegebene Entsprechung geändert
Zu den Ortschaften wurden Adressen und Straßenzahlen hinzugefügt
Die Bezirke von Vorortorten wurden zu einer einzigen zusammenhängenden Schicht von Ortschaften zusammengefasst – South Australian Hundreds wurden entfernt und ACT-Bezirke hinzugefügt, in denen es keine Ortschaften gibt, die im Amtsblatt aufgeführt sind
Der Ort Melbourne, VIC wurde in die Ortschaften Melbourne, 3000 und Melbourne 3004 aufgeteilt (die neuen Orts-PIDs sind loc9901d119afda_1 und loc9901d119afda_2 ). Die Aufteilung erfolgt am Yarra River (basierend auf den Postleitzahlen in den Adressen in Melbourne).
Mithilfe der Postleitzahlen in den Adresstabellen wurde ein Layer mit Postleitzahlengrenzen erstellt. Während dies den offiziellen Postleitzahlengrenzen von Geoscape sehr nahe kommt, gibt es mehrere hundert Adressen, die sich im falschen Postleitzahlenbereich befinden. Behandeln Sie diese Daten nicht als maßgeblich
