Ce chapitre documente les fonctionnalités trouvées dans le dossier extras des fichiers tarballs et du dépôt de sources de PostGIS. Celles-ci ne sont pas toujours packagées avec les versions binaires de PostGIS, mais sont généralement basées sur PL/pgSQL ou des scripts shell standard qui peuvent être exécutés tels quels.
Il s'agit d'un fork du PAGC standardizer (le code original de cette partie était PAGC PostgreSQL Address Standardizer).
Address standardizer est un analyseur d'adresses qui prend une adresse en entrée et la normalise sur la base d'un ensemble de règles stockées dans une table et des tables d'aide lex et gaz.
Le code est intégré dans une seule bibliothèque d'extension PostgreSQL appelée address_standardizer qui peut être installée avec CREATE EXTENSION address_standardizer;. En plus de l'extension address_standardizer, une extension de données d'exemple appelée address_standardizer_data_us extensions est construite, qui contient des tables de gaz, de lex et de règles pour les données américaines. Cette extension peut être installée via : CREATE EXTENSION address_standardizer_data_us;
Le code de cette extension se trouve dans le extensions/address_standardizer de PostGIS et est actuellement indépendant.
Pour les instructions d'installation, voir : Section 2.3, “Installation et utilisation de l'extension address standardize”.
L'analyseur fonctionne de droite à gauche en examinant d'abord les macroéléments (code postal, état/province, ville), puis les microéléments afin de déterminer s'il s'agit d'un numéro de maison, d'une rue, d'une intersection ou d'un point de repère. Pour l'instant, il ne recherche pas le code ou le nom du pays, mais cela pourrait être introduit à l'avenir.
- Code pays
On suppose qu'il s'agit des États-Unis ou du Canada sur la base des éléments suivants : code postal (États-Unis ou Canada), état/province (États-Unis ou Canada), autre (États-Unis)
- Code postal
Ils sont reconnus à l'aide d'expressions régulières compatibles avec Perl. Ces expressions régulières se trouvent actuellement dans le fichier parseaddress-api.c et sont relativement simples à modifier si nécessaire.
- État/province
Ils sont reconnus à l'aide d'expressions régulières compatibles avec Perl. Ces expressions régulières sont actuellement dans le fichier parseaddress-api.c mais pourraient être déplacées dans includes dans le futur pour faciliter la maintenance.
Cette section liste les types de données PostgreSQL installés par l'extension Address Standardizer. Notez que nous décrivons le comportement de casting (transformation du type) de ces types de données, ce qui est très important, en particulier lors de la conception de vos propres fonctions.
- stdaddr — Type composite composé des éléments d'une adresse. Il s'agit du type de retour de la fonction
standardize_address.
Cette section liste les formats de tables PostgreSQL utilisés par address_standardizer pour la normalisation des adresses. Notez que ces tables n'ont pas besoin d'être nommées de la même manière que ce qui est référencé ici. Vous pouvez avoir des tables lex, gaz, rules différentes pour chaque pays par exemple ou pour votre géocodeur personnalisé. Les noms de ces tables sont transmis aux fonctions de normalisation des adresses.
L'extension packagée address_standardizer_data_us contient des données pour la normalisation des adresses américaines.
- rules table — La table rules contient un ensemble de règles qui établit une correspondance entre les jetons de la séquence d'entrée de l'adresse et la séquence de sortie normalisée. Une règle est définie comme un ensemble de jetons d'entrée suivi de -1 (terminateur) suivi d'un ensemble de jetons de sortie suivi de -1 suivi d'un nombre indiquant le type de règle suivi du classement de la règle.
- lex table — La table lex est utilisée pour classer les entrées alphanumériques et les associer (a) à des jetons d'entrée (voir the section called “Jetons d'entrée”) et (b) à des représentations normalisées.
- gaz table — La table gaz est utilisée pour normaliser les noms de lieux et associer cette entrée avec (a) des tokens d'entrée ( Voir the section called “Jetons d'entrée”) et (b) des représentations normalisées.
- debug_standardize_address — Retourne une chaîne au format json avec les jetons d'entrée et les normalisations
- parse_address — Prend une adresse d'une ligne et la décompose en plusieurs parties
- standardize_address — Renvoie une forme stdaddr d'une adresse d'entrée en utilisant les tables lex, gaz et rule.
Un géocodeur basé sur plpgsql écrit pour fonctionner avec le TIGER (Topologically Integrated Geographic Encoding and Referencing system ) / Line and Master Address database export publié par le US Census Bureau.
Le géocodeur se compose de quatre éléments : les fonctions de chargement des données, le normalisateur d'adresses, le géocodeur d'adresses et le géocodeur inverse.
Bien qu'il soit conçu spécifiquement pour les États-Unis, un grand nombre de concepts et de fonctions sont applicables et peuvent être adaptés pour fonctionner avec les adresses et les réseaux routiers d'autres pays.
Le script construit un schéma appelé tiger pour héberger toutes les fonctions liées au tiger, les données de référence réutilisables telles que les préfixes de type de route, les suffixes, les états, diverses tables de contrôle pour gérer le chargement des données, et les tables de base squelettiques dont héritent toutes les tables chargées par le tiger.
Un autre schéma appelé tiger_data est également créé. Il contient toutes les données de recensement pour chaque État que le chargeur télécharge à partir du site du recensement et charge dans la base de données. Dans le modèle actuel, chaque ensemble de tables d'État est préfixé par le code de l'État, par exemple ma_addr, ma_edges etc. avec des contraintes pour appliquer uniquement les données de l'État. Chacune de ces tables hérite des tables addr, faces, edges, etc. situées dans le tiger schema.
Toutes les fonctions de géocodage ne font référence qu'aux tables de base, de sorte qu'il n'est pas nécessaire que le schéma de données s'appelle tiger_data ou que les données ne puissent pas être subdivisées en d'autres schémas - par exemple un schéma différent pour chaque État, tant que toutes les tables héritent des tables du schéma tiger.
Pour savoir comment activer l'extension dans votre base de données et charger des données à l'aide de celle-ci, consultez Section 2.4.1, “Tiger Geocoder Activation de votre base de données PostGIS”.
![[Note]](../images/note.png) | |
Si vous utilisez tiger geocoder (tiger_2010), vous pouvez mettre à jour les scripts en utilisant les scripts upgrade_geocoder.bat / .sh dans extras/tiger. Un changement majeur entre |
| |
Les nouveautés de la version 2.2.0 de PostGIS sont la prise en charge des données Tiger 2015 et l'intégration d'Address Standardizer dans PostGIS. La nouveauté de la version 2.1.0 de PostGIS est la possibilité d'installer le géocodeur tiger avec le modèle d'extension PostgreSQL si vous utilisez PostgreSQL 9.1+. Référez-vous à Section 2.4.1, “Tiger Geocoder Activation de votre base de données PostGIS” pour plus de détails. |
Le Pagc_Normalize_Address remplace directement le Normalize_Address intégré. Référez-vous à Section 2.3, “Installation et utilisation de l'extension address standardize” pour les instructions de compilation et d'installation.
Conception :
L'objectif de ce projet est de construire un géocodeur entièrement fonctionnel capable de traiter une chaîne d'adresses arbitraires aux États-Unis et, à l'aide des données normalisées du recensement TIGER, de produire une géométrie de points et une évaluation reflétant la localisation de l'adresse donnée et la vraisemblance de la localisation. Plus l'indice est élevé, plus le résultat est mauvais.
La fonction reverse_geocode, introduite dans PostGIS 2.0.0, est utile pour dériver l'adresse de la rue et les rues transversales d'une position GPS.
Le géocodeur doit être simple à installer et à utiliser pour toute personne familiarisée avec PostGIS, et doit être facilement installable et utilisable sur toutes les plateformes supportées par PostGIS.
Il doit être suffisamment robuste pour fonctionner correctement malgré les erreurs de formatage et d'orthographe.
Il doit être suffisamment extensible pour pouvoir être utilisé avec de futures mises à jour de données ou d'autres sources de données avec un minimum de changements de codage.
| |
Le schéma |
- Drop_Indexes_Generate_Script — Génère un script qui supprime toutes les clés non primaires et les index non uniques sur le schéma tiger et le schéma spécifié par l'utilisateur. Le schéma par défaut est
tiger_datasi aucun schéma n'est spécifié. - Drop_Nation_Tables_Generate_Script — Génère un script qui supprime toutes les tables du schéma spécifié qui commencent par
county_all,state_allou code d'état suivi decountyoustate. - Drop_State_Tables_Generate_Script — Génère un script qui supprime toutes les tables du schéma spécifié qui sont préfixées par l'abréviation de l'état. La valeur par défaut du schéma est
tiger_datasi aucun schéma n'est spécifié. - Geocode — Prend une adresse sous forme de chaîne de caractères (ou autre adresse normalisée) et produit un ensemble de lieux possibles comprenant une géométrie de point en NAD 83 long lat, une adresse normalisée pour chacun d'entre eux et l'évaluation. Plus la note est basse, plus la correspondance est probable. Les résultats sont triés par ordre décroissant. Il est possible d'indiquer en option le nombre maximum de résultats (10 par défaut) et la restriction de la région (NULL par défaut)
- Geocode_Intersection — Prend 2 rues qui s'intersectent et un état, une ville, un code postal, et produit un ensemble d'emplacements possibles sur la première rue croisée qui est à l'intersection, comprend également un "geomout" comme emplacement du point en NAD 83 long lat, une
adresse_normalisée(addy) pour chaque emplacement, et l'évaluation. Plus la note est basse, plus la correspondance est probable. Les résultats sont triés en fonction de la note la plus basse. Il est possible d'indiquer le nombre maximum de résultats, la valeur par défaut étant de 10. Utilise les données Tiger (edges, faces, addr), la correspondance floue de PostgreSQL (soundex, levenshtein). - Get_Geocode_Setting — Renvoie la valeur d'un paramètre spécifique stocké dans la table tiger.geocode_settings.
- Get_Tract — Renvoie le secteur de recensement ou le champ de la table des secteurs où se trouve la géométrie. Par défaut, le nom court du secteur est renvoyé.
- Install_Missing_Indexes — Recherche toutes les tables dont les colonnes clés sont utilisées dans les jointures du géocodeur et les conditions de filtrage qui n'ont pas d'index utilisés sur ces colonnes et les ajoute.
- Loader_Generate_Census_Script — Génère un script shell pour la plate-forme spécifiée et les états spécifiés qui téléchargera les tables de données Tiger census state tract, bg et tabblocks, les structurera et les chargera dans le schéma
tiger_data. Chaque script d'état est renvoyé sous la forme d'un enregistrement distinct. - Loader_Generate_Script — Génère un script shell pour la plateforme spécifiée et les états spécifiés qui téléchargera les données Tiger, les structurera et les chargera dans le schéma
tiger_data. Chaque script d'état est renvoyé sous la forme d'un enregistrement séparé. La dernière version prend en charge les modifications structurelles de Tiger 2010 et charge également les tableaux de secteurs de recensement, de groupes d'îlots et d'îlots. - Loader_Generate_Nation_Script — Génère un script shell pour la plate-forme spécifiée qui charge les données dans les tables county et state.
- Missing_Indexes_Generate_Script — Recherche toutes les tables dont les colonnes clés sont utilisées dans les jointures du géocodeur et qui n'ont pas d'index sur ces colonnes, et génère le DDL SQL permettant de définir l'index pour ces tables.
- Normalize_Address — Étant donné une adresse textuelle, cette fonction renvoie un type composite
norm_addyqui contient le suffixe de la route, le préfixe et le type normalisé, la rue, le nom de la rue, etc. divisés en champs distincts. Cette fonction fonctionne uniquement avec les données de recherche fournies avec le géocodeur tiger (pas besoin pour les données de recensement tiger). - Pagc_Normalize_Address — Étant donné une adresse textuelle, cette fonction renvoie un type composite
norm_addyqui contient le suffixe de la route, le préfixe et le type normalisé, la rue, le nom de la rue, etc. divisés en champs distincts. Cette fonction fonctionne uniquement avec les données de recherche fournies avec le géocodeur tiger (pas besoin pour les données de recensement tiger). Nécessite l'extension address_standardizer. - Pprint_Addy — Étant donné un objet de type composite
norm_addy, renvoie une jolie représentation de celui-ci. Généralement utilisé en conjonction avec normalize_address. - Reverse_Geocode — Prend un point géométrique dans un système spatial connu et renvoie un enregistrement contenant un tableau d'adresses théoriquement possibles et un tableau de rues transversales. Si include_strnum_range = true, la plage de rues est incluse dans les rues transversales.
- Topology_Load_Tiger — Charge une région définie de données tiger dans une topologie PostGIS et transforme les données tiger en référence spatiale de la topologie et en s'adaptant à la tolérance de précision de la topologie.
- Set_Geocode_Setting — Définit un paramètre qui affecte le comportement des fonctions du géocodeur.
Il existe quelques autres géocodeurs open source pour PostGIS qui, contrairement au géocodeur Tiger, présentent l'avantage de prendre en charge le géocodage multi-pays
Nominatim utilise les données formatées de OpenStreetMap gazeteer. Il nécessite osm2pgsql pour charger les données, PostgreSQL 8.4+ et PostGIS 1.5+ pour fonctionner. Il est présenté sous la forme d'une interface webservice et semble conçu pour être appelé en tant que webservice. Tout comme le tiger geocoder, il possède à la fois un géocodeur et un géocodeur inversé. La documentation n'indique pas clairement s'il dispose d'une interface SQL pure comme le géocodeur tiger, ou si une grande partie de la logique est implémentée dans l'interface web.
GIS Graphy utilise également PostGIS et, comme Nominatim, fonctionne avec des données OpenStreetMap (OSM). Il est livré avec un chargeur pour charger les données OSM et, comme Nominatim, il est capable de géocoder d'autres pays que les États-Unis. Tout comme Nominatim, il fonctionne comme un service web et s'appuie sur Java 1.5, Servlet apps, Solr. GisGraphy est multiplateforme et dispose également d'un géocodeur inversé parmi d'autres fonctionnalités intéressantes.