[postgis-users] Geocoder for PostGIS

[David Bitner]

Right now, that I know of, there are three existing PostGIS geocoders
that have opened thier code to public use/scrutiny:

Refractions (Tiger Data Only):  http://postgis.refractions.net/download/
Jocelyn Turcotte & Jean-Denis Giguere:
http://www.clepsydre.info/opengis/geocoder/geocode.tar.bz2
My own geocoder (PL/Perl and PL/PGSQL): http://foo.gyttja.org/geocoder.tar.gz

Are there any others that could be added to the list as possible
stepping off points?

On 8/15/05, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> 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
> >
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>