People by US city data: sources, fields and accuracy checks

The moment a city name becomes a pair of coordinates, it stops carrying its own uncertainty. A place known only to the municipality and a place known to the doorstep look identical once both are two decimal numbers, and every process downstream treats them as equally precise.

That flattening, and the small number of ways to prevent it, is what this page is about. The table shape and the provenance rules live on the state data page; this is the geography layer that sits on top.

What to take away

• Store the match type beside every coordinate. Without it, a place centroid and a street address are indistinguishable, and half your map is fictional precision.
• Never join on a place name. Use a stable geographic identifier from a published gazetteer such as the Geographic Names Information System, and record which vintage of the identifier set you used.
• Failed geocodes must fail loudly. A null coordinate is a fact; a zero coordinate is a phantom location that will appear on your map.

What a geocoder actually returns

A geocoder takes a text string and returns its best guess, with a quality grade attached. The grades matter more than the coordinates:

Match type	What the point means	Useful for
Parcel or rooftop	The structure itself	Nothing in this subject, and never for a living person
Street interpolation	An estimate along a block, by address number	Block-level questions, with the error understood
Postal code centroid	The middle of a set of delivery routes	Very coarse aggregation only
Place centroid	The middle of a municipality's polygon	Naming the municipality, not locating anything
County or state centroid	The middle of an administrative unit	A flag that the match failed

Most geocoding services will return something for almost any input, falling back to a coarser match rather than reporting failure. Historical addresses make this worse, because the units behind them changed between rounds, as the guide to census records shows. If you do not keep the match type column, that fallback is silent, and a record that resolved only to a state arrives in your file looking like an address.

Street interpolation deserves a specific warning. The coordinate is estimated by dividing a block's address range along its length, which assumes even spacing. Where numbering is irregular the point can land at the wrong end of the block, and where the range is assigned to the wrong side it lands across the street, which can be a different tract, a different ward and occasionally a different municipality.

Failed matches become clusters

The classic defect is storing an unmatched result as zero latitude and zero longitude. Those are valid coordinates, they sit in the ocean off West Africa, and every failed record in the file piles up there. Plotted, it is an obvious error. Aggregated into a country or region table, it silently becomes a population.

The same pattern occurs on land whenever failures default to a centroid: a large stack of records appears at the exact middle of a state or county, and because the location is plausible, nobody questions it. Any point that is repeated to full precision by many records is a defaulted point, not a place where things happened.

Store a failure as a null, keep the reason, and let anything that consumes the column decide what to do with a missing value.

Names are not identifiers

Place names repeat across the country, and they repeat inside single states. A lookup that resolves a name to a place by taking the largest candidate will quietly reassign small towns to big cities of the same name, and the error is invisible because the output is a real place.

Use the numeric geographic identifiers published by the statistical and mapping agencies, and store two things with them: which identifier system, and which vintage. Codes are added when places incorporate, retired when places dissolve or merge, and reused or renumbered between vintages. A join between two files built on different vintages will match most rows and mismatch some, which is the worst of both outcomes.

Keep the original place string in its own column forever. It is the only way to audit a match after the fact, and it is what you will need when a later vintage changes the answer.

Postal codes are routes, not areas

A postal code is a set of delivery routes maintained for mail, not a polygon and not a unit of government. Approximate polygons built from them are useful and are approximations; they cross municipal and county lines, they change when delivery changes, and some codes cover a single building or a set of post office boxes with no territory at all.

Joining anything to a place through a postal code therefore introduces an error that no amount of care downstream removes. Where the source gives you a postal code and you need a municipality, treat the result as a probable match with a confidence value, not as an assignment. The reason the postal name on an envelope is not the municipality is set out on the city pillar.

Counting records, not people

An aggregation counts rows. It counts people only if the rows are one per person, which they are not by default.

The same individual arrives from several sources, under variant spellings, and each arrival is a row. Deduplicate before aggregating, keep the merge decisions as their own records, and report both figures: distinct people, and total records. Where the two are far apart, the gap itself tells a reader which places have been indexed more than once, which is a fact about the sources and worth knowing. Where a search turned up nothing, log that too, in the form described on the search page.

Checks that catch geocoding defects

• Match type distribution. What share of your points are centroids? If it is large, your map is a map of place names.
• Precision against match type. Coordinates carried to six decimals on a place centroid match are false precision. Round the output to the match type.
• Points outside their stated boundary. Every point should fall inside the polygon of the place named in its own text column. Failures here are interpolation errors and bad matches.
• Repeated coordinates. Sort by coordinate and look for stacks. Legitimate stacks exist, at institutions for example, but most are defaults.
• Anachronistic geography. A point assigned to a municipality that did not exist on the record's date, a check that follows from the custodian and incorporation questions on the city facts page.

Living people, and what never enters the file

No address-level coordinate for a living person enters this data at any stage, including as an intermediate value that is later coarsened. Coarsening after the fact leaves the precise value in logs, in backups and in whatever the geocoding service retained.

More simply: we do not record where living people live. Where someone has publicly stated a place, the file stores the statement and its source, in text, without a coordinate.

Bottom line

A coordinate is a claim with a quality attached, and the quality lives in a separate column that most pipelines throw away. Keep the match type, keep the source string, fail loudly, join on identifiers with a vintage, and never let a geocoder invent a precision the record never had.

Common questions

Is a heat map of these points safe to publish?

Only with the match type distribution published beside it, and only described as a map of records. What area maps do to a reader, and the five ways they mislead without anyone lying, is covered under notability maps.

Should coordinates be recomputed when a geocoder improves?

Yes, and keep the old values as superseded rows with the date and the service version. A silent recompute changes published figures with no trace, and someone will eventually ask why last year's map differed.