[postgis-users] Geocoder for PostGIS

[Stephen Woodbridge]

Well, I for one would like to see it in postgres/postgis, but that 
doesn't stop us from building both or at least keep the project oriented 
toward collecting the information that is needed for any implementation 
in a common place.
For what its worth, Refractions has post a Tiger geocoder on their site, 
and Jocelyn Turcotte & Jean-Denis Giguere have post another geocoder 
that works out of postGIS.

I have looked over both of these and Schuyler's major deficit is in any 
smart address parsing and standardization. This will be the key to 
making a good geocoder. Parsing and standardization really needs to be 
dictionary based and pluggable.

Geocoding is nothing more than matching the address someone enters 
against a database to get a street segment and then interpolate along 
the segment to the house number  to get the location. The later part is 
just math, the database does the matching, but the really hard part is 
converting the address using country specific rules and standards and 
abbreviations and common miss spellings, etc into standardized tokens 
that can be matched.

If we can workout the design and algorithm issues, then it can easily be 
implemented in any language the support these goals.

-Steve


Paul Scott wrote:
>>>>abe.gillespie at gmail.com 08/15/05 4:36 PM >>>
> 
> I disagree with making a universal geocoder depend on PostGIS.  I
> think it's a better idea to have it completely independent of PostGIS.
> 
> 
> I must agree with this sentiment. I, personally, would rather go the
> route of a PHP, Perl or Python framework that could instantiate a
> country "module" as needed. Something like a core set of functions (db
> abstraction, output template etc) with a pluggable module for each
> country with the parcel specific data for that country/territory. That
> would make it a lot more efficient, as I would say only install the core
> + the South Africa module. 
> 
> The database should exist as it is, I wouldn't want to get too deep into
> that, rather use webservices (SOAP, REST etc) or a hardy abstraction
> layer to talk to the data. Let the scripting language do what it does
> best, that is parse the data to be useful to "end users", without
> putting unnecessary pressure on the db.
> 
> --Paul
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>