self-hosted/postgis
self-hosted/postgis
1
0
Fork 0
mirror of https://git.osgeo.org/gitea/postgis/postgis synced 2024-10-23 16:42:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix some typos in tiger geocoder documentation and hmm if Hudson is hiccuping (causing Olivier headaches), this might be the water he needs.

Browse source 
git-svn-id: http://svn.osgeo.org/postgis/trunk@7073 b70326c6-7e19-0410-871a-916f4a2858ee
This commit is contained in:
Regina Obe 2011-04-29 19:10:24 +00:00
parent c97e322a94
commit e57788448b
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/extras_tigergeocoder.xml
View file

@ -10,13 +10,13 @@
<para>Although it is designed specifically for the US, a lot of the concepts and functions are applicable and can be adapted to work with other country address and road networks.</para>
<para>The script builds a schema called <varname>tiger</varname> 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 from.</para>
<para>Another schema called <varname>tiger_data</varname> is also created which houses all the census data for each state that the loader downloads from 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, ca_edges etc with constraints to enforce only that state data. Each of these tables inherits from the base addr, faces, edgess, etc located in the tiger schema. </para>
prefixed with the state code e.g ma_addr, ca_edges etc with constraints to enforce only that state data. Each of these tables inherits from the base addr, faces, edges, etc located in the tiger schema. </para>
<para>All the geocode functions only reference the base tables, so there is no requirement that the data schema be called <varname>tiger_data</varname> 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 <varname>tiger</varname> schema.</para>
<para>Design:</para>
<para>The goal of this project is to build a fully functional geocoder that can process an arbitrary
address string and using normalized TIGER census data, produce a point geometry and rating reflecting the location of the given address and likeliness of the location.</para>
<para>Introduced in PostGIS 2.0.0 is a reverse geocoder useful for deriving the street address and cross streets of a GPS location.</para>
<para>The <varname>reverse_geocode</varname> function, introduced in PostGIS 2.0.0 is useful for deriving the street address and cross streets of a GPS location.</para>
<para>The geocoder should be simple for anyone familiar with PostGIS to install and use, and should be easily installable and usable on all platforms supported by PostGIS.</para>
<para>It should be robust enough to function properly despite formatting and spelling errors.</para>
<para>It should be extensible enough to be used with future data updates, or alternate data sources with a minimum of coding changes.</para>
@ -25,8 +25,8 @@
</sect1info>
<para>There is another geocoder for PostGIS gaining in popularity and more suitable for international use. It is called <ulink url="http://wiki.openstreetmap.org/wiki/Nominatim">Nominatim</ulink>
and uses OpenStreetMap gazeteer formatted data. It requires osm2pgsql for loading the data, PostgreSQL 8.4+ and PostGIS 1.5+ to function. It also a webservice interface and was more designed to be call as a webservice.
Just like the tiger geocoder, it has both a geocoder and 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.</para>
and uses OpenStreetMap gazeteer formatted data. It requires osm2pgsql for loading the data, PostgreSQL 8.4+ and PostGIS 1.5+ to function. 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.</para>
<refentry id="Geocode">
<refnamediv>