This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
I'm interested in getting census block IDs for an address list. I thought that the US geocoder would only assign a censusID to the appropriate geographic scale: ZIP5 = County, ZIP9 = Block, etc, but I'm getting a full census block ID for addresses coded to ZIP5 which makes me think these CensusIDs are not accurate. Can I get some clarification?
I used the US Geocoder tool with the TomTom US - Most Recent Vintage geocoder. I matched and geocoded, and used the Zip9 geocoder for failed records. I've attached a sample of addresses that were coded at the ZIP5 geolevel, but have block IDs.
Thanks for all the documentation. Unfortunately, I was not able to access the first link you included.
According to the US Census, a census ID down to block level is a "15-character code that is the concatenation of fields consisting of the 2-character state FIPS code, the 3-character county FIPS code, the 6-character census tract code, and the 4-character tabulation block code." (Source) So it seems to me that if an address geocodes to the ZIP5 level and only has a CensusID down to the county level that it should only be 5 digits long. However, I'm seeing all CensusIDs having 15 digits.
So, take one of the addresses in my list that is incorrectly formatted (8788 Portland, OR 97207). This address can only be geocoded to the ZIP5 level, and according to the documentation you provided, it should have a CensusID only showing granularity to the county level, but it includes a CensusID of 410510056004011. What it appears is happening is the geocoder tool is pulling the census block closest to the lat lon resulting from the geocode. The problem is it is almost certainly the wrong block, and shouldn't even try to do this.
I use the US Geocoder tool regularly, and consider it the best geocoder tool I've ever used, so I don't want to make too much of an issue of this. I have given people lists with census IDs before believing that the results are accurate though. In the future, I will have to be a bit more careful about how I share these Block IDs. Perhaps this is something that the Alteryx developers could take a look at. Or if there's a setting we're missing that would correct this, I'd love to know about it!
When using the Street Geocoder alone (image above), the ZIP5 Census ID is clearly not a complete code. Seems like adding in the other address coding features (CASS and ZIP9) forces an inaccurate value. The US Geocoder Macro can be opened and edited. If there is a different routing option of uncoded records you'd like to see, please suggest. I can also discuss this with the data team and see if there might be other ways to handle this.
Thanks for bringing up the topic. Let's see if we can clarify the end result. Lonnie
It looks like the ZIP9 Coder tool includes a 15 digit CensusID for ZIP5, ZIP7, and ZIP9, and then that value takes precedence over the Street Geocoder values in the US Geocoder tool. These are more niche cases, so it's not a huge deal in the long run, but I did modify my work flow to get things looking a little better. I also noticed that the ZIP5 points from the Street Geocoder and Z9 Geocoder tools differ. Not sure why.
I believe it's just ZIP5. My guess is the ZIP9 geocoder uses a different ZIP5 centroid list than the street geocoder.
I'm also finding a number of addresses that match to the TomTom list but end up with the wrong CensusID. This appears to be a TomTom issue since the CensusID is pulled from TomTom's list. Unless there's a good reason not to, I plan on using the best geocode available and then intersecting my list with the Census Block shapefile from US Census Bureau.
Mike, additional information about the differences in ZIP Centroids in the Street/US Geocoder vs ZIP9 Codes - different methodologies. (Thanks to @EricM and @SaraK for their research!)
The ZIP 5 source for the Street Geocoder is the same as the US VGF source. We use the Spatial Info tool to find the centroid of each ZIP poly, and use that to load the geocoder database.
The ZIP source for the ZIP 9 coder is the MNP file from TomTom, which gives us each zip 5 with a fixed pair of coordinates that represent the centroid.
i.e., the Street Geocoder ZIP centroids are derived from Polys using the spatial info tool. ZIP Centroids in the ZIP 9 coder are derived using a table of ZIPs & coordinates that TomTom gives us.
Why the different methodologies? The Street Geocoder product came first and we created centroids using the best methodology at that time. When the ZIP9 Coder was created, the methodologies were not synchronized.