Un moyen rapide de charger le fichier complet d'adresses nationales géocodées de l'Australie (GNAF) et les limites administratives australiennes dans Postgres, simplifié et prêt à être utilisé comme données de référence pour le géocodage, l'analyse, la visualisation et l'agrégation.
Jetez un œil à ces diapositives d’introduction (PDF), ainsi qu’à la page data.gov.au.
Exécutez le script Python load-gnaf et créez vous-même la base de données en une seule étape
Extrayez la base de données de Docker Hub et exécutez-la dans un conteneur
Téléchargez les fichiers de dump GNAF et/ou Admin Bdys Postgres et restaurez-les dans votre base de données Postgres 14+
Utilisez ou téléchargez les fichiers Geoparquet et Parquet dans S3 pour vos flux de données et d'analyse ; soit sur AWS, soit sur votre propre plateforme.
L'exécution du script Python prend 30 à 120 minutes sur un serveur Postgres configuré pour tirer parti de la RAM disponible.
Vous pouvez traiter la version GDA94 ou GDA2020 des données - assurez-vous simplement de télécharger la même version pour le GNAF et les limites administratives. Si vous ne savez pas ce qu'est GDA94 ou GDA2020, téléchargez les versions GDA94 (pour information, ce sont des systèmes de coordonnées différents)
Pour obtenir un bon temps de chargement, vous devrez configurer votre serveur Postgres pour ses performances. Il y a un bon guide ici, notant qu'il date de quelques années et que certains paramètres de mémoire peuvent être renforcés si vous disposez de la RAM.
Postgres 14.x et supérieur avec PostGIS 3.2+
Ajoutez le répertoire bin Postgres au PATH de votre système
Python 3.6+ avec Psycopg 3.x
Téléchargez Geoscape GNAF depuis data.gov.au (GDA94 ou GDA2020)
Téléchargez les limites administratives de Geoscape depuis data.gov.au ( téléchargez la version ESRI Shapefile (GDA94 ou GDA2020) )
Décompressez GNAF dans un répertoire de votre serveur Postgres
Décompressez Admin Bdys dans un répertoire local
Modifiez la sécurité sur ces répertoires pour accorder un accès en lecture à Postgres
Créer la base de données cible (si nécessaire)
Ajoutez PostGIS à la base de données (si nécessaire) en exécutant le code SQL suivant : CREATE EXTENSION postgis
Vérifiez les arguments disponibles et requis en exécutant load-gnaf.py avec l'argument -h (voir les exemples de ligne de commande ci-dessous)
Exécutez le script, revenez dans 30 à 120 minutes et profitez-en !
Le comportement de gnaf-loader peut être contrôlé en spécifiant diverses options de ligne de commande dans le script. Les arguments pris en charge sont :
--gnaf-tables-path spécifie le chemin d'accès aux fichiers GNAF PSV extraits. Ce répertoire doit être accessible par le serveur Postgres , et le chemin local correspondant du serveur vers ce répertoire devra peut-être être défini via l'argument local-server-dir
--local-server-dir spécifie le chemin local sur le serveur Postgres correspondant à gnaf-tables-path . Si le serveur s'exécute localement, cet argument peut être omis.
--admin-bdys-path spécifie le chemin d'accès aux fichiers de limites d'administration Shapefile extraits. Contrairement à gnaf-tables-path , ce chemin ne doit pas nécessairement être accessible au serveur Postgres distant.
--pghost le nom d'hôte du serveur Postgres. La valeur par défaut est la variable d'environnement PGHOST si elle est définie, sinon la valeur par défaut est localhost .
--pgport le numéro de port du serveur Postgres. La valeur par défaut est la variable d'environnement PGPORT si elle est définie, sinon 5432 .
--pgdb le nom de la base de données du serveur Postgres. La valeur par défaut est la variable d'environnement PGDATABASE si elle est définie, sinon geoscape .
--pguser le nom d'utilisateur pour accéder au serveur Postgres. La valeur par défaut est la variable d'environnement PGUSER si elle est définie, sinon postgres .
--pgpassword mot de passe pour accéder au serveur Postgres. La valeur par défaut est la variable d'environnement PGPASSWORD si elle est définie, sinon password .
--srid Définit le système de coordonnées des données d'entrée. Les valeurs valides sont 4283 (la valeur par défaut : GDA94 lat/long) et 7844 (GDA2020 lat/long).
--geoscape-version Numéro de version de Geoscape au format AAAAMM. La valeur par défaut est l'année en cours et le mois de la dernière version. par exemple 202408 .
--previous-geoscape-version Numéro de version de la version précédente de Geoscape au format AAAAMM ; utilisé pour la comparaison d’assurance qualité. par exemple 202405 .
--raw-gnaf-schema nom du schéma dans lequel stocker les tables GNAF brutes. La valeur par défaut est raw_gnaf_ .
--raw-admin-schema nom du schéma dans lequel stocker les tables de limites d'administration brutes. La valeur par défaut est raw_admin_bdys_ .
--gnaf-schema nom du schéma de destination dans lequel stocker les tables GNAF finales. La valeur par défaut est gnaf_ .
--admin-schema nom du schéma de destination dans lequel stocker les tables de limites d'administration finales. La valeur par défaut est admin_bdys_ .
--previous-gnaf-schema Schéma avec la version précédente des tables GNAF. La valeur par défaut est gnaf_ .
--previous-admin-schema Schéma avec la version précédente des tables de limites d'administration. La valeur par défaut est admin_bdys_ .
--states liste d'états séparés par des espaces à charger, par exemple --states VIC TAS . Par défaut, le chargement de tous les états est effectué.
--prevacuum force le nettoyage de la base de données après la suppression de tables. La valeur par défaut est désactivée et la spécification de cette option ralentira le processus d'importation.
--raw-fk crée des clés primaires et étrangères pour les tables GNAF brutes. La valeur par défaut est désactivée et ralentira le processus d'importation si spécifié. Utilisez cette option si vous avez l'intention d'utiliser les tables GNAF brutes comme autre chose qu'une étape d'importation temporaire. Notez que les tables finales traitées auront toujours un jeu de clés primaires et étrangères appropriées.
--raw-unlogged crée des tables GNAF brutes non enregistrées, accélérant ainsi l'importation. La valeur par défaut est désactivée. Ne spécifiez cette option que si vous ne vous souciez pas des tables de données brutes après l'importation - elles seront perdues si le serveur plante !
--max-processes spécifie le nombre maximum de processus parallèles à utiliser pour le chargement des données. Définissez ceci sur le nombre de cœurs sur le serveur Postgres moins 2, mais limitez-le à 12 si plus de 16 cœurs - il y a un avantage minime au-delà de 12. La valeur par défaut est 4.
--no-boundary-tag NE marquez PAS toutes les adresses avec certains des ID de limite d'administrateur clés pour créer des agrégats et des cartes choroplèthes.
Serveur Postgres local : python load-gnaf.py --gnaf-tables-path="C:tempgeoscape_202408G-NAF" --admin-bdys-path="C:tempgeoscape_202408Administrative Boundaries" Charge les tables GNAF sur un serveur Postgres exécuté localement. Les archives GNAF ont été extraites dans le dossier C:tempgeoscape_202408G-NAF et les limites d'administration ont été extraites dans le dossier C:tempgeoscape_202408Administrative Boundaries .
Serveur Postgres distant : python load-gnaf.py --gnaf-tables-path="svrsharedgnaf" --local-server-dir="f:sharedgnaf" --admin-bdys-path="c:tempunzippedAdminBounds_ESRI" Charge le Tables GNAF qui ont été extraites dans le dossier partagé svrsharedgnaf . Ce dossier partagé correspond au dossier local f:sharedgnaf sur le serveur Postgres. Les limites d'administration ont été extraites dans le dossier c:tempunzippedAdminBounds_ESRI .
Chargement uniquement des états sélectionnés : python load-gnaf.py --states VIC TAS NT ... Charge uniquement les données pour Victoria, la Tasmanie et le Territoire du Nord.
Vous pouvez charger les limites administratives sans GNAF. Pour ce faire : commentez les étapes 1, 3 et 4 dans def main.
Remarque : vous ne pouvez pas charger GNAF sans l'Admin Bdys en raison des dépendances nécessaires pour diviser Melbourne et pour corriger les locality_pids non limites sur les adresses.
Lorsque vous utilisez les données résultant de ce processus, vous devrez respecter les exigences d'attribution sur les pages data.gov.au pour GNAF et Admin Bdys, dans le cadre des exigences de licence de données ouvertes.
Les scripts supprimeront toutes les tables en utilisant CASCADE dans les schémas GNAF et Admin Bdy, puis les recréeront ; ce qui signifie que vous PERDREZ VOS VUES si vous en avez créé ! Si vous souhaitez conserver les données existantes, vous devrez modifier les noms de schéma dans le script ou utiliser une autre base de données.
Toutes les tables GNAF brutes peuvent être créées NON ENREGISTRÉES pour accélérer le chargement des données. Cela les rendra IRRÉCUPÉRABLES si votre base de données est corrompue. Vous pouvez réexécuter ces scripts pour les recréer. Si vous pensez que cela semble correct, définissez l'indicateur unlogged_tables sur True pour un chargement légèrement plus rapide.
Le balisage des limites (activé par défaut) ajoutera 15 à 60 minutes au processus si vous disposez de PostGIS 2.2+. Si vous disposez de PostGIS 2.1 ou d'une version antérieure, cela peut prendre des HEURES car les tables de limites ne peuvent pas être optimisées !
Bien que vous puissiez choisir les 4 schémas dans lesquels charger les données, je n'ai pas vérifié chaque permutation. Restez fidèle aux valeurs par défaut si vous avez une expérience limitée de Postgres
Si vous n'exécutez pas le script Python sur le serveur Postgres, vous devrez avoir accès à un chemin réseau vers les fichiers GNAF sur le serveur de base de données (pour créer la liste des fichiers à traiter). L'alternative est d'avoir une copie locale des fichiers bruts
Le script SQL « Créer des tables » ajoutera l'extension PostGIS à la base de données dans le schéma public, vous n'avez pas besoin de l'ajouter à votre base de données
Il existe une option pour VIDE la base de données au début après avoir supprimé les tables GNAF/Admin Bdy existantes - cela ne fait vraiment rien en dehors de tests répétés. (J'étais trop paresseux pour le retirer du code car cela signifiait renuméroter tous les fichiers SQL et j'aimerais aller me coucher maintenant)
GNAF et les limites d'administration sont prêts à être utilisés dans Postgres dans une image sur Docker Hub.
Dans votre environnement Docker, extrayez l'image à l'aide docker pull minus34/gnafloader:latest
Exécuter en utilisant docker run --publish=5433:5432 minus34/gnafloader:latest
Accédez à Postgres dans le conteneur via le port 5433 . La connexion par défaut est - utilisateur : postgres , mot de passe : password
Remarque : l'image Docker compressée fait 8 Go, celle non compressée est de 25 Go.
AVERTISSEMENT : le mot de passe du superutilisateur Postgres par défaut n'est pas sécurisé et doit être modifié à l'aide de :
ALTER USER postgres PASSWORD '
Téléchargez les fichiers de dump Postgres et restaurez-les dans votre base de données.
Cela devrait prendre 15 à 60 minutes.
Postgres 14+ avec PostGIS 3.0+
Une connaissance des paramètres pg_restore de Postgres
Téléchargez le fichier de vidage GNAF ou le fichier de vidage GNAF GDA2020 (~ 2,0 Go)
Téléchargez le fichier de vidage Admin Bdys ou le fichier de vidage Admin Bdys GDA2020 (~ 2,8 Go)
Modifiez le script restaurer-gnaf-admin-bdys.bat ou .sh dans le dossier supports-files pour les noms de vos fichiers de vidage, les paramètres de base de données et pour l'emplacement de pg_restore
Exécutez le script, revenez dans 15 à 60 minutes et profitez-en !
Les versions Geoparquet des tables spatiales, ainsi que les versions parquet des tables non spatiales, se trouvent dans un compartiment S3 public pour une utilisation directe dans une application ou un service. Ils peuvent également être téléchargés à l'aide de l'AWS CLI.
Les géométries ont des coordonnées latitude/longitude WGS84 (SRID/EPSG :4326). Un exemple de requête pour analyser les données à l'aide d'Apache Sedona, l'extension spatiale d'Apache Spark se trouve dans le dossier spark .
Les fichiers sont ici : s3://minus34.com/opendata/geoscape-202408/geoparquet/
Répertoriez tous les ensembles de données : aws s3 ls s3://minus34.com/opendata/geoscape-202408/geoparquet/
Copiez tous les ensembles de données : aws s3 sync s3://minus34.com/opendata/geoscape-202408/geoparquet/
Incorpore ou est développé à l'aide de G-NAF © Geoscape Australia sous licence du Commonwealth d'Australie dans le cadre du contrat de licence d'utilisateur final Open Geo-coded National Address File (G-NAF).
Incorpore ou est développé en utilisant les limites administratives © Geoscape Australia sous licence du Commonwealth d'Australie sous la licence internationale Creative Commons Attribution 4.0 (CC BY 4.0).
GNAF et Admin Bdys ont été personnalisés pour supprimer certaines des limitations mineures connues des données. Les plus notables sont :
Toutes les adresses renvoient à une localité classée qui a une limite. Le petit nombre d'adresses qui ne figurent pas dans le GNAF brut ont vu leur locality_pid remplacé par un équivalent publié dans la Gazette.
Les localités ont reçu des adresses et des décomptes de rues ajoutés
Les districts de banlieue et de localité ont été aplatis en une seule couche continue de localités - Des centaines d'Australie du Sud ont été supprimées et des districts ACT ont été ajoutés là où il n'y a pas de localités classées.
La localité de Melbourne, VIC, a été divisée en localités Melbourne, 3000 et Melbourne 3004 (les nouveaux PID de localité sont loc9901d119afda_1 et loc9901d119afda_2 ). La séparation se produit au bord de la rivière Yarra (sur la base des codes postaux des adresses de Melbourne)
Une couche de limites de codes postaux a été créée à l'aide des codes postaux dans les tables d'adresses. Bien que cela émule fidèlement les limites officielles du code postal de Geoscape, plusieurs centaines d'adresses se trouvent dans le mauvais groupe de code postal. Ne traitez pas ces données comme faisant autorité
