1

I'm using the TIGER geocoder (2013 data, PostGIS 2.1, Postgres 9.3) to geocode intersections in New York City, but I'm finding that if I omit the zip code, I almost never get a match. So, for example...

ny_tiger=# SELECT pprint_addy(addy), st_astext(geomout), rating FROM
  geocode_intersection('Broadway', 'Houston St', 'NY', 'New York', '10012');
       pprint_addy            |          st_astext          | rating 
----------------------------------+-----------------------------+--------
 607 Broadway, New York, NY 10012 | POINT(-73.996772 40.725432) |      0
 604 Broadway, New York, NY 10012 | POINT(-73.996772 40.725432) |      0
 609 Broadway, New York, NY 10012 | POINT(-73.996772 40.725432) |      0
 606 Broadway, New York, NY 10012 | POINT(-73.996772 40.725432) |      0
(4 rows)

but...

ny_tiger=# SELECT pprint_addy(addy), st_astext(geomout), rating FROM
  geocode_intersection('Broadway', 'Houston St', 'NY', 'New York');                                                                                           
 pprint_addy | st_astext | rating 
-------------+-----------+--------
(0 rows)

Is there a good way to get these addresses to resolve without the zip code?

1

It should be able to so sounds like it might be a bug. Without zip it should just take a little longer. I'm the one that wrote this function, and I would like this in our bug tracker so I can check out the issue when I have the time. I unfortunately don't have NY data loaded so will take me a bit more time.

Instructions for posting a bug to our bug tracker are here: http://postgis.net/support

For tiger geocoder pick component: tiger_geocoder

Now for debugging this particular issue, the geocoder comes with a function:

http://postgis.net/docs/manual-2.1/Set_Geocode_Setting.html

If you do:

SELECT set_geocode_setting('debug_geocode_intersection', 'true');

And then rerun your query, then it should spit out the query it is running in notice (messages tab of pgAdmin)

I'm guessing it has to do with the hard-coded limits I put in and that Houston and Broadway are kind of common, so without the zip your answer doesn't fall in the 5000 limit. You can try running the debug query output and try increasing that 5000 to something a bit higher to see if it works.

When you are done debugging:

    SELECT set_geocode_setting('debug_geocode_intersection', 'false');

So you don't get a lot of junk in your pg_logs.

Hope that helps, Regina

  • Thanks, Regina. I've opened a ticket here: trac.osgeo.org/postgis/ticket/2734. It contains the output of the debugger. – futuraprime May 13 '14 at 19:44
  • Thanks. Did you try increasing the 5000 limit? We are releasing a 2.1.3 soon, so can't make the cut there but hope to have resolved in 2.1.4 – LR1234567 May 13 '14 at 20:17
  • I didn't--I'm not sure how to change that setting. Is there another set_geocode_setting option for it, or do I need to run this long query manually? – futuraprime May 13 '14 at 22:40
  • No it's in the tiger.geocode_intersection function -- I was thinking for starters you'd just run the debugged sql that got spit out changing the LIMIT 5000 to something like LIMIT 10000. There is also a LIMIT 1000 you'd want to try upping too. If that works then you can directly change the code in the function. – LR1234567 May 14 '14 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.