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.
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)
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.
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.
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.
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”.
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 |
tiger_data
si aucun schéma n'est spécifié.
county_all
, state_all
ou code d'état suivi de county
ou state
.
tiger_data
si aucun schéma n'est spécifié.
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).
tiger_data
. Chaque script d'état est renvoyé sous la forme d'un enregistrement distinct.
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.
norm_addy
qui 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).
norm_addy
qui 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.
norm_addy
, renvoie une jolie représentation de celui-ci. Généralement utilisé en conjonction avec normalize_address.
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.