-1

When I geocode an address using PostGIS+TIGER 2013 I get a different city than what Census Bureau Geocoder reports. The Long/Lat are identical in both cases, but the PLACEFP is different although both geocoders return same Tiger Line ID.

Census Geocoder is supposed to use the same TIGER Datafile. I can't understand why they come up with a different city name result than what is in the TIGER data?

Here's concrete: Addr: "2721 Montavo Pl 95008"

Census Geocoder: http://geocoding.geo.census.gov/geocoder/geographies/address?street=2721+montavo+pl&city=&state=&zip=95008&benchmark=9&vintage=910

Matched Address: 2721 Montavo Pl, CAMPBELL, CA, 95008
Coordinates:X: -121.93808 Y: 37.272305
Tiger Line Id: 618196302 Side: L

Now, Postgis 2.1.4 using TIGER 2013 data:

SELECT g.rating, ST_X(g.geomout) As lon, ST_Y(g.geomout) As lat, 
(addy).address As stno, (addy).streetname As street, 
(addy).streettypeabbrev As styp, (addy).location As city, (addy).stateabbrev As st,(addy).zip 
FROM geocode(pagc_normalize_address('2721 montavo pl 95008')) As g LIMIT 1; 

 rating |        lon        |       lat        | stno | street  | styp |   city   | st |  zip  
--------+-------------------+------------------+------+---------+------+----------+----+-------
      5 | -121.937982751719 | 37.2723357046132 | 2721 | Montavo | Pl   | San Jose | CA | 95008

You can notice the 2 different city names: Campbell vs San Jose although the Tiger Line ID is identical.

So I looked inside the tables in TIGER using the Tiger Line Id returned by Census own geocoder, as follows:

select * from edges where tlid = 618196302 limit 1;

gid        | 3147591
statefp    | 06
countyfp   | 085
tlid       | 618196302
tfidl      | 261702284
tfidr      | 261702284
mtfcc      | S1640
fullname   | Montavo Pl
smid       | 5437
lfromadd   | 2701
ltoadd     | 2799
rfromadd   | 2700
rtoadd     | 2798
zipl       | 95008
zipr       | 95008
featcat    | S
hydroflg   | N
railflg    | N
roadflg    | Y
olfflg     | N
passflg    | 
divroad    | 
exttyp     | N
ttyp       | 
deckedroad | 
artpath    | N
persist    | 
gcseflg    | N
offsetl    | N
offsetr    | N
tnidf      | 409324023
tnidt      | 409323983

and from here down to faces table using tfid=261702284:

select * from faces where tfid = 261702284 limit 1;

gid        | 2034060
tfid       | 261702284
puma5ce00  | 
statefp    | 06
countyfp   | 085
tractce    | 502701
blkgrpce   | 3
blockce    | 3001
cousubfp   | 92830
submcdfp   | 
conctyfp   | 
placefp    | 68000
aiannhfp   | 
aiannhce   | 
comptyp    | 
trsubfp    | 
trsubce    | 
anrcfp     | 
ttractce   | 
tblkgpce   | 
elsdlea    | 07140
scsdlea    | 07230
unsdlea    | 
uace       | 
cd111fp    | 18
sldust     | 015
sldlst     | 028
vtdst      | 
zcta5ce    | 
tazce      | 
ugace      | 
puma5ce    | 
csafp      | 488
cbsafp     | 41940

Note now the PLACEFP=68000 which gives us the actual city name, so I go to place table:

select * from place where placefp = '68000' limit 1;

gid      | 3120
statefp  | 06
placefp  | 68000
placens  | 02411790
plcidfp  | 0668000
name     | San Jose
namelsad | San Jose city
lsad     | 25
classfp  | C1
cpi      | 
pcicbsa  | Y
pcinecta | N
mtfcc    | G4110
funcstat | A
aland    | 457309699
awater   | 10237236
intptlat | +37.2967394
intptlon | -121.8189089

So Placename is San Jose. According to TIGER data the PostGIS is CORRECT, however, Census Geocoder returns Campbell AND indeed I want Cambpell. Where is Census Geocoder getting that info from?

I checked the actual shapefile the_geom, the address is NOT in the geom for Campbell... however where is Census Geocoder coming with Campbell from then?

Thanks!

  • My mailing address puts my in a city for which the boundary is a good 15 minute drive away (so the census might not put me there) -- is this possibly a disparity between actual location and mailing address location? – Erica Oct 18 '14 at 19:08
  • As I said, the Long/Lat is correct in both cases. That is NOT the issue. The issue is the actual city name that the 2 geocoders return. – Biba Oct 18 '14 at 19:16
  • 1
    I think you're misunderstanding what Erica is saying. Addresses can be assigned zip codes for different cities than that in which they physically lie. That address appears to be right at or on the boundary between San Jose and Campbell. Zip codes and addresses are delivery routes, not geographic areas. The physical address may be in San Jose, but its mail delivery and addressing through Campbell. And looking up Campbell on Google Maps, so that it shows the boundary, confirms this - the address is physically in San Jose. – Chris W Oct 18 '14 at 19:42
  • I understand that, however it is not the issue at hand. The issue is Census geocoder returns a different city from what Census own TIGER datafile has on record as 2013. – Biba Oct 18 '14 at 19:43
  • 2
    Without knowing the details of how the geocoders/address locators are constructed, it's hard to say for sure. But I suspect the Census Geocoder is returning a city based off the Zip and not the TLID (and further chained data) of the edge. If you look at the edge/TLID record, the zip is given. Query based on that and you'll get Campbell, the address city. But if you query based on faces, as the rest of your question shows, you end up at the physical city. It's the same data, it's just following a different chain of attributes to arrive at two different answers (both correct). – Chris W Oct 18 '14 at 20:39
0

Well, I did email the guys at US Census/TIGER and amazingly they did answer next day. In short, Chris W's observation is correct and they use USPS Zip to City as overrider even the TIGER data clearly points at a different Place(San Jose). I suspect some city boundaries have expanded however TIGER doesn't reflect it in the data file yet. Most likely TIGER contains the Political geoshapes and it's not necessarily what a specific Resident identifies as his/her City boundary. Excerpt from US Census response:

"The geocoder uses the ZIP to City name as a reference/search option only. It is based off the USPS provided linkage and does not use TIGER data at all to arrive at the name.

In many cases, this is helpful in getting positive address results, particularly when a city name is provided, but a ZIP is not. Obviously, 95008 is an exception to this, as I assume a resident at the address you provided would designate their city name as San Jose and not Campbell. But it's the hope that the usage of the USPS provided city names would yield more results overall."

  • 1
    I'm sure some municipal boundaries have changed, but I don't think that's the root issue. USPS is its own entity and sets and revises its own boundaries on a not infrequent basis. As I said, zip codes are delivery routes, not geographic areas. Consider anyone living in an unincorporated part of a county. They have a city in their address (that of wherever their post office is located) even though they don't actually reside in the city. The same happens in dense urban areas in cases like this, where USPS needs to balance loads and routes between different cities that make up a metro area. – Chris W Oct 20 '14 at 19:33

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.