1

I have encountered an address that appears to be giving the PostGIS TIGER geocoder a hard time. I've loaded the geocoder with the 2015 data, which includes the following in the ma_edges table:

gis=# select fullname, lfromadd,ltoadd,rfromadd,rtoadd,zipl,zipr from tiger_data.ma_edges where fullname like 'Preble Garden%';
    fullname    | lfromadd | ltoadd | rfromadd | rtoadd | zipl  | zipr  
----------------+----------+--------+----------+--------+-------+-------
 Preble Gardens | 2        | 98     | 1        | 99     | 02478 | 02478
(1 row)

And yet, attempts to geocode an address like 20 PREBLE GARDENS, BELMONT, MA 02478 results in an odd failure:

gis=# select geocode('20 PREBLE GARDENS, BELMONT, MA 02478');
                                        geocode                                        
---------------------------------------------------------------------------------------
 ("(,,,,,,Belmont,MA,01773,t)",0101000020AD10000076014F81DDD351C0999B13B16D364540,100)
(1 row)

I am confused on multiple accounts:

  • First, it seems as if the address falls solidly inside the address bounds in the ma_edges table, so I'm not clear why it's failing in the first place.
  • Secondly, I am puzzled how it is ending up with the wrong zip code (01773, which is Lincoln, MA) despite having the correct city and state.

For the curious, the debug about that results when setting the various geocoder debug_* settings to true is available here.

It looks like maybe the geocoder is trying to replace the phrase "Gardens" with the abbreviation "Gdns", which I guess would explain the first problem, but I'm still unclear why the second problem is happening.

Can you provide any insight on what's going on here?

3

I checked this. The problem seems to be that in the data GARDENS is part of the street name, but the normalizer breaks out GARDENS as a street_type

Curiously leaving out the GARDENS actually works

select geocode('20 PREBLE, BELMONT, MA 02478');

outputs

("(20,,""Preble Gardens"",,,,Belmont,MA,02478,t)",0101000020AD1000008A5D7106D9CA51C0BEAEFA46C9304540,80)

which I would have expected to fail as well.

Regarding the replacing of Gardens with abbreviation GDNS. Yah that's another thing too, but doesn't seem to be the culprit in this case. If you for example update the table:

UPDATE tiger.street_type_lookup 
   SET abbrev = 'GARDENS' WHERE name = 'GARDENS';

You'll see it no longer abbreviates, but still doesn't return the right answer.

However if you completely delete the record GARDENS from the lookup table so GARDENS is no longer considered a street type it will work.

DELETE FROM street_type_lookup where name = 'GARDENS';

Mind putting this in our bug tracker, and I'll investigate more later when I have the time - http://postgis.net/support/

I'm suspecting the best solution is for me to just delete that record from the lookup table, but I need to verify with other state data, that GARDENS is never considered a street type.

  • Thanks for the answer. I will try and file a bug, but first I need to figure out how to reset an osgeo account password, which seems oddly complicated... – larsks Dec 14 '15 at 0:44

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.