Chapter 12. PostGIS Extras

Table of Contents

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.

12.1. Address Standardizer

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”.

12.1.1. Fonctionnement de l'analyseur

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.

12.1.2. Types de normalisateurs d'adresses

Abstract

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.

12.1.3. Tables Address Standardizer

Abstract

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.

12.1.4. Fonctions Address Standardizer

  • 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.

12.2. Géocodeur Tiger

Abstract

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”.

[Note]

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 tiger_2010 and tiger_2011+ is that the county and state tables are no longer broken out by state. If you have data from tiger_2010 and want to replace with tiger_2015, refer to Section 2.4.4, “Mise à jour du géocoder Tiger et de ses données”

[Note]

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.

[Note]

Le schéma tiger doit être ajouté au search path de la base de données pour que les fonctions fonctionnent correctement.

  • 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_data si 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_all ou code d'état suivi de county ou state.
  • 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_data si 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_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).
  • Pagc_Normalize_Address — Étant donné une adresse textuelle, cette fonction renvoie un type composite 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.
  • 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.

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.