Dieses Kapitel beschreibt Funktionen, die sich in dem Verzeichnis "extras" des PostGIS Quellcodes (Tarball oder Repository) befinden. Diese sind nicht immer mit der binären PostGIS Release paketiert, es handelt sich dabei aber üblicherweise um Pl/Pgsql- oder Shell-Skripts, die direkt aufgerufen werden können.
Dies ist ein Entwicklungszweig des PAGC Adressennormierers (der Code für diesen Teilbereich beruht auf dem PAGC Adressennormierer für PostgreSQL).
Der Adressennormierer ist ein Parser für einzeilige Adressen. Eine gegebene Adresse wird anhand von in einer Tabelle abgelegten Regeln und den Hilfstabellen "lex" und "gaz" normiert.
Der Code befindet sich in einer einzelnen PostgreSQL Erweiterungsbibliothek mit der Bezeichnung address_standardizer und kann mittels CREATE EXTENSION address_standardizer; installiert werden. Zusätzlich zu der Erweiterung "address_standardizer" gibt es auch die Erweiterung address_standardizer_data_us, welche die Tabellen "gaz", "lex" und "rules" für Daten der USA enthält. Diese Erweiterung kann mittels CREATE EXTENSION address_standardizer_data_us; installiert werden.
Der Code für diese Erweiterung befindet sich unter PostGIS in extensions/address_standardizer und ist zurzeit self-contained ("unabhängig").
Für eine Installationsanleitung siehe: Section 2.3, “Installation und Verwendung des Adressennormierers”.
Der Parser arbeitet von rechts nach links und betrachtet zunächst die Makroelemente Postleitzahl, Staat/Provinz, Stadt. Anschließend werden die Mikroelemente untersucht, um festzustellen ob es sich um eine Husnummer, eine Kreuzung oder eine Wegmarkierung handelt. Zur Zeit schaut der Parser nicht auf die Landeskennzahl oder -namen, dies kann aber möglicherweise noch implementiert werden.
- Country code
Wird als US oder CA basiert angenommen: Postleitzahl als US oder Kanada, state/province als US oder Kanada, sonst US
- Postcode/zipcode
Diese werden über Perl-kompatible reguläre Ausdrücke erkannt. Die Regexs befinden sich in "parseaddress-api.c" und können bei Bedarf relativ leicht angepasst werden.
- State/province
Diese werden über Perl-kompatible reguläre Ausdrücke erkannt. Die Regexs befinden sich zurzeit in "parseaddress-api.c", könnten zukünftig aber zwecks leichterer Wartbarkeit in die "includes" verschoben werden.
Dieser Abschnitt listet die von der Erweiterung "Address Standardizer" installierten PostgreSQL-Datentypen auf. Beachten Sie bitte die hier beschriebene Verhaltensweise bei der Typumwandlung. Diese ist insbesondere dann sehr wesentlich, wenn Sie Ihre eigenen Funktionen entwerfen.
- stdaddr — Ein zusammengesetzter Datentyp, der aus den Elementen einer Adresse besteht. Dies ist der zurückgegebene Datentyp der
standardize_addressFunktion.
Dieser Abschnitt beschreibt den Aufbau der PostgreSQL Tabellen, die von dem "address_standardizer" bei der Normalisierung von Adressen verwendet werden. Diese Tabellen können auch anders als hier bezeichnet werden. Sie können eigene "lex", "gaz" und "rules" Tabellen für jedes Land oder für einen benutzerdefinierten Geokodierer verwenden. Diese Tabellennamen werden an die Funktionen des Adressennormierers übergeben.
Das Erweiterungspaket address_standardizer_data_us enthält Daten zum Normieren von US Adressen.
- rules table — Die Tabelle "rules" enthält die Regeln, nach denen die Token der Eingabesequenz der Adresse in eine standardisierte Ausgabesequenz abgebildet werden. Eine Regel besteht aus einem Satz Eingabetoken, gefolgt von -1 (Terminator), gefolgt von einem Satz Ausgabetoken, gefolgt von -1, gefolgt von einer Zahl zur Kennzeichnung des Regeltyps, gefolgt von der Rangordnung der Regel.
- lex table — Eine "lex" Tabelle wird verwendet, um eine alphanumerische Eingabe einzustufen und mit (a) Eingabe-Tokens (siehe the section called “Eingabe-Token”) und (b) normierten Darstellungen zu verbinden.
- gaz table — Eine "gaz" Tabelle wird verwendet, um Ortsnamen zu normieren und um diese mit (a) Eingabe-Token (siehe the section called “Eingabe-Token”) und (b) normierten Darstellungen zu verbinden.
- debug_standardize_address — Returns a json formatted text listing the parse tokens and standardizations
- parse_address — Nimmt eine 1-zeilige Adresse entgegen und zerlegt sie in die Einzelteile
- standardize_address — Gibt eine gegebene Adresse in der Form "stdaddr" zurück. Verwendet die Tabellen "lex", "gaz" und "rule".
Ein auf PL/pgSQL basierender Geokodierer, der für das vom United States Census Bureau herausgegebene TIGER (Topologically Integrated Geographic Encoding and Referencing system ) / Line and Master Address database export geschrieben wurde.
Der Geokodierer besteht aus vier Komponenten: Funktionen zum Laden von Daten, der Adressennormierer, der Adressengeokodierer und der inverse Geokodierer.
Obwohl speziell für die US entworfen, können viele Konzepte und Funktionen übernommen und an die Adressen und Straßennetze anderer Länder angepasst werden.
Das Skript erstellt ein Schema mit der Bezeichnung tiger, in dem sich alle auf TIGER bezogenen Funktionen befinden, sowie wiederverwendbare Daten, wie Präfixe für Straßentypen, Suffixe, Länder, verschiedene Kontrolltabellen zum Bewerkstelligen des Ladens von Daten, und Schablonen für die Basistabellen von denen alle geladenen TIGER-Tabellen erben.
Eine weiteres Schema mit der Bezeichnung tiger_data enthält die Volkszählungsdaten aller Länder, die der Loader von der Census Seite in die Datenbank lädt. Im aktuellen Datenmodell erhalten die Tabellen eines Landes den Ländercode als Präfix - z.B. ma_addr, ma_edges etc. - und werden mit Constraints versehen, welche die Daten auf das jeweilige Land beschränken. Diese Tabellen erben alle von den Tabellen addr, faces, edges, etc., die sich in dem Schema tiger befinden.
Da die Funktionen zur Geokodierung nur auf die Basistabellen verweisen, muss das Datenschema nicht notwendigerweise tiger_data heissen. Solange alle Tabellen von den Tabellen im Schema tiger erben, können die Daten auch auf andere Schemata weiter aufgeteilt werden -- z.B. ein anderes Schema für jedes Land.
Anweisungen wie Sie die EXTENSION in Ihrer Datenbank aktivieren und mit ihr Daten laden können, finden Sie unter Section 2.4.1, “Tiger Geocoder Enabling your PostGIS database”.
![[Note]](../images/note.png) | |
Wenn Sie den Tiger Geokodierer (tiger_2010) verwenden, können Sie die Skripts mit den beigefügten Shell-Skripts "upgrade_geocoder.bat" unter "extras/tiger" aktualisieren. Eine wesentliche Änderung zwischen |
| |
Neu in der PostGIS 2.2.0 Release ist die Unterstützung von Tiger 2015 Daten und die Einbindung des Adressennormierers als Teil von PostGIS. Falls Sie mit PostgreSQL 9.1+ arbeiten, haben Sie mit der PostGIS 2.1.0 Release die neue Möglichkeit, den Tiger Geokodierer mittels dem PostgreSQL Extension Modell zu installieren. Siehe Section 2.4.1, “Tiger Geocoder Enabling your PostGIS database” für Details. |
Die Funktion Pagc_Normalize_Address kann direkt gegen die eingebaute Funktion Normalize_Address ausgetauscht werden. Siehe Section 2.3, “Installation und Verwendung des Adressennormierers” für Anweisungen zur Kompilation und Installation.
Entwurf:
Das Ziel des Projektes ist einen voll funktionsfähigen Geokodierer zu erstellen, der eine beliebige Adresszeile der USA verarbeiten kann. Mittels normalisierter TIGER Census Daten wird eine Punktgeomtrie und eine Wertung erstellt, welche die Lage einer gegebenen Adresse mit einer bestimmten Wahrscheinlichkeit darstellen. Umso höher die Wertung ist, umso schlechter ist das Ergebnis.
Mit der Funktion reverse_geocode, die in PostGIS 2.0.0 eingeführt wurde, können mittels Geokoordinaten textuelle Lokationsangaben, wie Adressen und Straßenkreuzungen bestimmt werden.
Der Geokodierer sollte von jedem, der mit PostGIS vertraut ist, leicht zu installieren und zu benutzen sein. Er sollte auch auf allen von PostGIS unterstützten Plattformen installierbar und benutzbar sein.
Abgesehen von Formatierungs- und Rechtschreibfehlern, sollte der Geokodierer stabil genug sein um einwandfrei zu funktionieren.
Er sollte auch ausreichend erweiterbar sein, um zukünftige Datenaktualisierungen durchzuführen und alternativen Datenquellen mit geringen Änderungen des Codes zu nutzen.
| |
Damit die Funktionen ordnugsgemäß arbeiten, muss das |
- Drop_Indexes_Generate_Script — Erzeugt ein Skript, welches alle Indizes aus dem Datenbankschema "Tiger" oder aus einem vom Anwender angegebenen Schema löscht, wenn die Indizes nicht auf den Primärschlüssel gelegt und nicht "unique" sind. Wenn kein Schema angegeben ist wird standardmäßig auf das
tiger_dataSchema zugegriffen. - Drop_Nation_Tables_Generate_Script — Erzeugt ein Skript, welches alle Tabellen in dem angegebenen Schema löscht, die mit
county_all,state_alloder dem Ländercode gefolgt voncountyoderstatebeginnen. - Drop_State_Tables_Generate_Script — Erzeugt ein Skript, dass alle Tabellen in dem angegebenen Schema löscht, die als Präfix einen Ländercode haben. Wenn kein Schema angegeben ist wird standardmäßig auf das
tiger_dataSchema zugegriffen. - Geocode — Nimmt eine Adresse als Zeichenkette (oder eine bereits standardisierte Adresse) entgegen und gibt die möglichen Punktlagen zurück. Die Ausgabe beinhaltet eine Punktgeometrie in NAD 83 Länge/Breite, eine standardisierte Adresse und eine Rangfolge (Rating) für jede Punktlage. Umso niedriger die Rangfolge ist, um so wahrscheinlicher ist die Übereinstimmung. Die Ergebnisse werden mit aufsteigender Rangfolge sortiert - dar niedrigste Rang zuerst. Optional kann die maximale Anzahl der Ergebnisse angegeben werden (Standardeinstellung ist 10) und der Bereich mit restrict_region beschränkt werden (Standardeinstellung ist NULL)
- Geocode_Intersection — Nimmt 2 sich kreuzende Straßen, einen Bundesstaat, eine Stadt und einen ZIP-Code entgegen und gibt die möglichen Punktlagen an der ersten Querstraße an der Kreuzung zurück. Die Ausgabe beinhaltet auch die Geometrie "geomout" in NAD 83 Länge/Breite, eine standardisierte Adresse
normalized_address(addy) für jede Punktage, sowie die Rangfolge. Umso niedriger die Rangfolge ist, um so wahrscheinlicher ist die Übereinstimmung. Die Ergebnisse werden mit aufsteigender Rangfolge sortiert - dar niedrigste Rang zuerst. Optional kann die maximale Anzahl der Ergebnisse angegeben werden (Standardeinstellung ist 10). Verwendet TIGER Daten (Kanten, Maschen, Adressen) und Fuzzy String Matching (soundex, levenshtein) von PostgreSQL. - Get_Geocode_Setting — Gibt die in der Tabelle "tiger.geocode_settings" gespeicherten Einstellungen zurück.
- Get_Tract — Gibt für die Lage einer Geometrie die Census Area oder ein Feld der tract-Tabelle zurück. Standardmäßig wird die Kurzbezeichnung der Census Area ausgegeben.
- Install_Missing_Indexes — Findet alle Tabellen mit Schlüsselspalten, die für JOINs und Filterbedingungen vom Geokodierer verwendet werden und keinen Index aufweisen; die fehlenden Indizes werden hinzugefügt.
- Loader_Generate_Census_Script — Erzeugt für gegebene Plattform und Bundesstaaten ein Shellskript, das die TIGER Datentabellen "tract", "bg" und "tabblocks" herunterlädt, bereitstellt und in das Schema
tiger_dataimportiert. Jedes Bundesstaat-Skript wird in einem eigenen Datensatz ausgegeben. - Loader_Generate_Script — Erzeugt für gegebene Plattform und Bundesstaaten ein Shellskript, das die TIGER Daten herunterlädt, bereitstellt und in das Schema
tiger_dataimportiert. Jedes Bundesstaat-Skript wird in einem eigenen Datensatz ausgegeben. Die neueste Version unterstützt die geänderte Struktur von Tiger 2010 und lädt ebenfalls die Census Tract, Block Groups und Blocks Tabellen. - Loader_Generate_Nation_Script — Erzeugt für die angegebene Plattform ein Shell-Skript, welches die County und State Lookup Tabellen ladet.
- Missing_Indexes_Generate_Script — Findet alle Tabellen mit Schlüsselspalten, die für JOINs vom Geokodierer verwendet werden und keinen Index aufweisen; gibt ein DDL (SQL) aus, dass die Indizes für diese Tabellen festlegt.
- Normalize_Address — Für einen gegebenen Adressentext wird der zusammengesetzte Datentyp
norm_addyzurückgeben, der ein Suffix und ein Präfix für die Straße, einen normierten Datentyp, die Straße, den Straßennamen etc. enthält und diese einzelnen Attributen zuweist. Diese Funktion benötigt lediglich die "lookup data", die mit dem Tiger Geokodierer paketiert sind (Tiger Census Daten werden nicht benötigt). - Pagc_Normalize_Address — Für einen gegebenen Adressentext wird der zusammengesetzte Datentyp
norm_addyzurückgeben, der ein Suffix und ein Präfix für die Straße, einen normierten Datentyp, die Straße, den Straßennamen etc. enthält und diese einzelnen Attributen zuweist. Diese Funktion benötigt lediglich die "lookup data", die mit dem Tiger Geokodierer paketiert sind (Tiger Census Daten werden nicht benötigt). Benötigt die Erweiterung "address_standardizer". - Pprint_Addy — Für einen zusammengesetzten Objekttyp
norm_addywird eine formatierte Darstellung zurückgegeben. Wird üblicherweise in Verbindung mit normalize_address verwendet. - Reverse_Geocode — Nimmt einen geometrischen Punkt in einem bekannten Koordinatenreferenzsystem entgegen und gibt einen Datensatz zurück, das ein Feld mit theoretisch möglichen Adressen und ein Feld mit Straßenkreuzungen beinhaltet. Wenn include_strnum_range = true, dann beinhalten die Straßenkreuzungen den "Street Range" (Kennung des Straßenabschnitts).
- Topology_Load_Tiger — Lädt die Tiger-Daten einer bestimmte Region in die PostGIS Topologie, transformiert sie in das Koordinatenreferenzsystem der Topologie und fängt sie entsprechend der Genauigkeitstoleranz der Topologie.
- Set_Geocode_Setting — Setzt die Einstellungen, welche das Verhalten der Funktionen des Geokodierers beeinflussen.
Es existieren eine Reihe weiterer Open Source Geokodierer füf PostGIS, welche im Gegensatz zu dem Tiger Geokodierer den Vorteil haben, dass sie mehrere Länder unterstützen
Nominatim verwendet Daten von OpenStreetMap, die mittels Gazetteer formatiert werden. Es benötigt osm2pgsql zum Laden der Daten, PostgreSQL 8.4+ und PostGIS 1.5+ um zu funktionieren. Es ist als Webinterface paketiert und wird vermutlich als Webservice aufgerufen. So wie der Tiger Geokodierer besteht es aus einem Geokodierer und einer inversen Komponente des Geokodierers. Aus der Dokumentation ist nicht ersichtlich, ob es wie der Tiger Geokodierer auch eine reine SQL Schnittstelle aufweist, oder ob ein größerer Anteil der Logik in das Webinterface implementiert wurde.
GIS Graphy nützt ebenfalls PostGIS und arbeitet so wie Nominatim ebenfalls mit Daten von OpenStreetMap (OSM). Es beinhaltet einen Loader, um OSM-Daten zu importieren. Ähnlich wie Nominatim kann es auch für die Geokodierung außerhalb der USA verwendet werden. So wie Nominatim läuft es als Webservice und benötigt Java 1.5, Servlet Apps und Solr. GisGraphy kann plattformübergreifend genutzt werden und hat ebenfalls einen invertierten Geokodierer zusammen mit anderen geschickten Funktionen.