[postgis-users] geo-coding question

[Lee Keel]

> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net [mailto:postgis-users-
> bounces at postgis.refractions.net] On Behalf Of Stephen Woodbridge
> Sent: Wednesday, June 27, 2007 10:39 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] geo-coding question
> 
> Lee,
> 
> The refractions team work a geocoder in pgsql procedures that assumes
> some Tiger data has been loaded. There are occasional requests for help
> on loading data, but I'm not sure if there is an explicit well defined
> procedure for that. I think the PostGIS geocoder was written as a proof
> of concept and I am not aware of anyone using it in a production
> environment. OracleSpatial geocoder is a mature production quality
> geocoder, but it expects Navteq data, or data that can get munged into
> Navteq format.
> 
> The difficult part of geocoding is handling address standardization and
> handling fuzzy searching. Once you can standardize the addresses the
> query part is trivial in comparison. Much of the Oracle's geocoder is
> written in Java in their application server.
> 
> -Steve
> 
> 

Steve,

You are absolutely correct that the most difficult part of the geocoding
process is the address parsing.  We have spent many hours refining our
parser to work as much as possible and we have some more to go.

The website that I sent before is in a "production" environment.  We are
using postgres plpgsql functions to do our geocoding against the full US
Tiger 2006 2nd Ed dataset.  I agree that there is probably not an explicit
well defined procedure for loading the Tiger data.  We currently are
converting the data to shapefiles, then importing the shapefiles with a
little messaging done after that.  Of course that will change in the next
Tiger release when the data is available in shapefiles already.  But even
then, it is obvious that any geocoder that is using tables for address
parsing will be expecting certain tables to exist with certain columns.  I
don't know any way around that part of it. 

We have gotten around a lot of the need for fuzzystring matching by doing
the live search.  So the user can quickly and easily see their selection
within the dropdown as they are typing.  We have been working on a
fuzzystring match side for another page that has a different purpose, but
that is probably round 2.

I know the OracleSpatial geocoder is a LOT more mature than what we have,
but what we have is a pretty good starting point.  We definitely have some
enhancements left to be made, but I thought this live geocoding search is a
pretty good show case for the speed of postgres\postgis against a roads
table of more than 39 million rows.

Regards,
Lee Keel
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.