Tiger Geocoder 2010 normalize_address bug - postDirAbbrev doesn't parse

[mikepease]

The post direction suffix (North) does not get parsed in the normalize_address().

—misses the "north" suffix select * from normalize_address('212 3rd Ave N Minneapolis, MN 55401')

—the "north" *prefix* works select * from normalize_address('212 N 3rd Ave Minneapolis, MN 55401')

—finds the "north" suffix when a suite # is added to the address select * from normalize_address('212 3rd Ave N Suite 560, Minneapolis, MN 55401')

I'm using 2010 Tiger_geocoder downloaded in June 2011 and I'm running on Postgresql 8.4.8 for Windows (Vista) and have PostGIS 1.5.2 installed.

[mikepease]

I believe this normalize_address bug leads to a geocoder() bug that I'm running into frequently. I am getting the wrong geocode for streets with a direction suffix.

For example: select g.* from geocode('240 Plato Blvd E, Saint Paul, MN 55107') as g

This incorrectly geocodes to 240 Plato Blvd *West*, nearly a mile to the west of the actual location. Many of the addresses in my database have N/S E/W distinctions and it appears that the Tiger geocoder isn't finding the correct location for these addresses.

[robe]

Mike I checked my current build and this works fine. So I suspect you just need to update your geocoder. In the tiger folder, there is an update_geocoder.bat script that should bring you up to date. Give it a try.

When I run these — this is what I get:

select * from normalize_address('212 3rd Ave N Minneapolis, MN 55401') ;
 address | predirabbrev | streetname | streettypeabbrev | postdirabbrev | internal |  location   | stateabbrev |  zip  | parsed 
---------+--------------+------------+------------------+---------------+----------+-------------+-------------+-------+--------
     212 |              | 3rd        | Ave              | N             |          | Minneapolis | MN          | 55401 | t
(1 row)

select * from normalize_address('212 N 3rd Ave Minneapolis, MN 55401') ;
 address | predirabbrev | streetname | streettypeabbrev | postdirabbrev | internal |  location   | stateabbrev |  zip  | parsed 
---------+--------------+------------+------------------+---------------+----------+-------------+-------------+-------+--------
     212 | N            | 3rd        | Ave              |               |          | Minneapolis | MN          | 55401 | t

[mikepease]

Hi, Regina. Thanks for looking into this. Unfortunately, it's still not working for me.

I did an SVN update for this repository at: ​http://svn.osgeo.org/postgis/trunk/extras/tiger_geocoder/tiger_2010

It downloaded a few changed files. I then edited upgrade_geocoder.bat to have my database connection info in it. And then I ran it in a command prompt window. All appeared to run properly. But, my normalize_address() queries are still not finding the postdirabbrev properly.

Is there a way for me to easily verify that I'm running the same version you are? Any comment in the SQL functions or something?

Could there be an issue that I'm running this on Postgres 8.4.8 and PostGIS 1.5.2 instead of Postrgres 9.0 / PostGIS 2.0?

Here's some sample queries. First the type the doesn't work and then variations that do work. Seems to parse the postdirabbrev if there is no street type or if there is an "internal" component (e.g. suite number). —doesn't get postdirabbrev select * from normalize_address('212 3rd Ave N, Minneapolis, MN 55401') ; —this works select * from normalize_address('212 3rd N, Minneapolis, MN 55401') ; —this works select * from normalize_address('212 3rd Ave N Suite 560, Minneapolis, MN 55401') ; —this works select * from normalize_address('212 N 3rd Ave, Minneapolis, MN 55401') ;

Thanks for the help. I hope I can get this working. If not, I probably can't use the Tiger Geocoder for my project because my database has lots of addresses with "N/S" suffixes.

[robe]

No no comment, though that would be a good thing to add. I can add a function or something that outputs the revision. I'll double-check by reloading mine. It might either be something I fixed locally that I didn't commit or something I broke that I commit.

The 1.5.2 shouldn't be an issue. I'm running on a 9.0 1.5.2 install for most of my tests.

Thanks, Regina

[robe]

Mike,

Sorry I misread what you wrote — I see the issue now is with this query:

select * from normalize_address('212 3rd Ave N, Minneapolis, MN 55401') 

and I was testing this query:

select * from normalize_address('212 3rd Ave N Minneapolis, MN 55401') ;

So I see the issue now.

[robe]

fixed at r7462

[mikepease]

Hi, Regina. I got your latest code and your changes worked! Super! normalize_address() now seems to get the direction suffix properly.

However, I'm still having an issue with the geocode() function incorrectly choosing the wrong street, getting the "North" street instead of the "South" street for example. Here's an example in downtown Minneapolis, MN where the Avenue numbers split in the middle of the city 1st-10th Ave North and 1st-10th Ave South.

—This incorrectly geocodes to 150 2nd Ave *South* instead of north

select (g.addy).*, astext(g.geomout), g.* from geocode('150 2nd Ave S, Minneapolis, MN 55401') as g

—This fuzzy match does find 150 2nd Ave *South* in its list of candidate matches

select (g.addy).*, astext(g.geomout), g.* from geocode('150 2nd, Minneapolis, MN 55401') as g

Since the fuzzy match finds the correct street in its list, there appears to be an error in selecting the correct street for and exact match.

Let me know what you find with this. Thanks for all the quick work! Mike

[robe]

You mean incorrectly geocodes as North instead of South right?

[robe]

fixed at r7474

[Sandro Santilli <strk@…>]

In 64239b7/git:

Fix the unit test

References #1051, same as normalize_address_regress.
All 3 tests passed.

Origin: GH-784