Spectrum Technology Platform

Disclaimer: these opinions are my own and do not reflect those of the Census Bureau or any other federal agency. These are my observations as a data consumer and not as a data provider.

The TomTom streets geocoding database with vintage 2022.1 (Geocoding TT Street US, KGD) is returning incorrect Census data in the CensusBlockID and CensusTract fields when it cannot geocode to the block level. This vintage is the first with 2020 Census geography. It appears to be returning the correct CensusBlockID and CensusTract values when it can geocode to the block level. However, when it geocodes to the tract or block group level, it appears to be returning 2010 Census geography. This mix of Census tabulation geographies is a catastrophic data quality issue. This occurs in all 50 states and DC.

For an example, I used Geocode US Address in the Enterprise Geocoding Module, configured with the 2022.1 vintage. I input just City, StateProvince, and PostalCode as "Harrisburg", "AR", and "72432". The resulting CensusBlockID is '05111490500' and CensusTract is '490500'. However, no such tract exists in 2020 Census geography. That is from 2010 Census geography. For 2020 geography, Harrisburg is in tracts 490501 and 490502.

Contrast this by geocoding a specific address in Harriburg (look one up -- I didn't include any here as to not transmit sensitive data). Note that the CensusTract value and tract portion of CensusBlockID are correctly populated with '490501'.

Again, this mix of 2010 and 2020 Census geography occurs in every state. This makes the 2022.1 TomTom streets database *unusable* for anyone who uses CensusBlockID and CensusTract values when an address cannot be geocoded to the block level.

Disclaimer: these opinions are my own and do not reflect those of the Census Bureau or any other federal agency. These are my observations as a data consumer and not as a data provider.

The TomTom streets geocoding database with vintage 2022.1 (Geocoding TT Street US, KGD) is returning incorrect Census data in the CensusBlockID and CensusTract fields when it cannot geocode to the block level. This vintage is the first with 2020 Census geography. It appears to be returning the correct CensusBlockID and CensusTract values when it can geocode to the block level. However, when it geocodes to the tract or block group level, it appears to be returning 2010 Census geography. This mix of Census tabulation geographies is a catastrophic data quality issue. This occurs in all 50 states and DC.

For an example, I used Geocode US Address in the Enterprise Geocoding Module, configured with the 2022.1 vintage. I input just City, StateProvince, and PostalCode as "Harrisburg", "AR", and "72432". The resulting CensusBlockID is '05111490500' and CensusTract is '490500'. However, no such tract exists in 2020 Census geography. That is from 2010 Census geography. For 2020 geography, Harrisburg is in tracts 490501 and 490502.

Contrast this by geocoding a specific address in Harriburg (look one up -- I didn't include any here as to not transmit sensitive data). Note that the CensusTract value and tract portion of CensusBlockID are correctly populated with '490501'.

Again, this mix of 2010 and 2020 Census geography occurs in every state. This makes the 2022.1 TomTom streets database *unusable* for anyone who uses CensusBlockID and CensusTract values when an address cannot be geocoded to the block level.

Disclaimer: these opinions are my own and do not reflect those of the Census Bureau or any other federal agency. These are my observations as a data consumer and not as a data provider.

The TomTom streets geocoding database with vintage 2022.1 (Geocoding TT Street US, KGD) is returning incorrect Census data in the CensusBlockID and CensusTract fields when it cannot geocode to the block level. This vintage is the first with 2020 Census geography. It appears to be returning the correct CensusBlockID and CensusTract values when it can geocode to the block level. However, when it geocodes to the tract or block group level, it appears to be returning 2010 Census geography. This mix of Census tabulation geographies is a catastrophic data quality issue. This occurs in all 50 states and DC.

For an example, I used Geocode US Address in the Enterprise Geocoding Module, configured with the 2022.1 vintage. I input just City, StateProvince, and PostalCode as "Harrisburg", "AR", and "72432". The resulting CensusBlockID is '05111490500' and CensusTract is '490500'. However, no such tract exists in 2020 Census geography. That is from 2010 Census geography. For 2020 geography, Harrisburg is in tracts 490501 and 490502.

Contrast this by geocoding a specific address in Harriburg (look one up -- I didn't include any here as to not transmit sensitive data). Note that the CensusTract value and tract portion of CensusBlockID are correctly populated with '490501'.

Again, this mix of 2010 and 2020 Census geography occurs in every state. This makes the 2022.1 TomTom streets database *unusable* for anyone who uses CensusBlockID and CensusTract values when an address cannot be geocoded to the block level.

Disclaimer: these opinions are my own and do not reflect those of the Census Bureau or any other federal agency. These are my observations as a data consumer and not as a data provider.

The TomTom streets geocoding database with vintage 2022.1 (Geocoding TT Street US, KGD) is returning incorrect Census data in the CensusBlockID and CensusTract fields when it cannot geocode to the block level. This vintage is the first with 2020 Census geography. It appears to be returning the correct CensusBlockID and CensusTract values when it can geocode to the block level. However, when it geocodes to the tract or block group level, it appears to be returning 2010 Census geography. This mix of Census tabulation geographies is a catastrophic data quality issue. This occurs in all 50 states and DC.

For an example, I used Geocode US Address in the Enterprise Geocoding Module, configured with the 2022.1 vintage. I input just City, StateProvince, and PostalCode as "Harrisburg", "AR", and "72432". The resulting CensusBlockID is '05111490500' and CensusTract is '490500'. However, no such tract exists in 2020 Census geography. That is from 2010 Census geography. For 2020 geography, Harrisburg is in tracts 490501 and 490502.

Contrast this by geocoding a specific address in Harriburg (look one up -- I didn't include any here as to not transmit sensitive data). Note that the CensusTract value and tract portion of CensusBlockID are correctly populated with '490501'.

Again, this mix of 2010 and 2020 Census geography occurs in every state. This makes the 2022.1 TomTom streets database *unusable* for anyone who uses CensusBlockID and CensusTract values when an address cannot be geocoded to the block level.