Lee,
Another question, can you talk about how you are doing your livesearch?
Is this doing a fulltext search, are you parsing the incoming address
string and generating dynamic queries?
For example: "543 Hough St, Illinois" does not filter non Illinois
addresses. Are you only searching for the street name? What happens when
you search for something common like "101 main st" It seems you only
return 12 results, What if you put them in a grid as permalinks, and
then you could page through the results like 12 at a time to see more.
Anyway, just some ideas. I like it.
-Steve
Lee Keel wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:postgis-users-
[EMAIL PROTECTED] 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.
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
