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.
A plpgsql based geocoder written to work with the TIGER (Topologically Integrated Geographic Encoding and Referencing system ) / Line and Master Address database export released by the 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.
The script builds a schema called tiger to house all the TIGER-related functions, reusable lookup data such as road type prefixes, suffixes, states, various control tables for managing data load, and skeleton base tables from which all the TIGER-loaded tables inherit.
Another schema called tiger_data is also created which houses all the census data for each state that the loader downloads from the Census site and loads into the database. In the current model, each set of state tables is prefixed with the state code e.g ma_addr, ma_edges etc with constraints to enforce only that state data. Each of these tables inherits from the tables addr, faces, edges, etc located in the tiger schema.
All the geocode functions only reference the base tables, so there is no requirement that the data schema be called tiger_data or that data can't be further partitioned into other schemas -- e.g. a different schema for each state, as long as all the tables inherit from the tables in the tiger schema.
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”.
|
|
|
If you are using the TIGER Geocoder (tiger_2010), you can upgrade the scripts using the accompanying upgrade_geocoder.bat / .sh scripts in extras/tiger. One major change between |
|
|
|
You can install the TIGER Geocoder with the PostgreSQL extension model. Refer to Section 2.4.1, “Tiger Geocoder Activation de votre base de données PostGIS” for details. |
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.
The reverse_geocode function is useful for deriving the street address and cross streets of a GPS location.
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.
There are a couple other open source geocoders for PostGIS, that unlike the TIGER Geocoder have the advantage of multi-country geocoding support
Nominatim uses OpenStreetMap gazeteer formatted data. It requires osm2pgsql for loading the data together with PostgreSQL and PostGIS. It is packaged as a webservice interface and seems designed to be called as a webservice. Just like the TIGER Geocoder, it has both a geocoder and a reverse geocoder component. From the documentation, it is unclear if it has a pure SQL interface like the TIGER Geocoder, or if a good deal of the logic is implemented in the web interface.
GIS Graphy can utilize PostGIS and like Nominatim uses OpenStreetMap (OSM) data along with some other sources. It comes with a loader to load OSM data and similar to Nominatim is capable of geocoding not just US. Much like Nominatim, it runs as a webservice and relies on Java 1.5, Servlet apps, Solr. GisGraphy is cross-platform and also has a reverse geocoder among some other neat features.