Publish geographic data with clear place codes, boundaries and units

To publish a spreadsheet of facilities by district, start by making the geography explicit—not by choosing a map. Readers need to know which place each row describes, what the numbers measure and whether the areas are comparable.

Geographic data is information tied to a location or area. In a spreadsheet, that connection might be an address, latitude and longitude, or a code identifying a country, county or district. A useful public table preserves that connection alongside the measurements and source notes.

1. Define what one row represents

Choose a consistent row structure before cleaning the file:

• Locations: one row per facility, with a facility ID and public address or coordinates.
• Area statistics: one row per area and reporting period, with an area code and measurement.
• Events: one row per event, with an event ID, date and an appropriate public location.

Do not mix individual facilities, district totals and national totals as though they were equivalent observations. Separate them, or label their geographic levels clearly and prevent double-counting.

Here is a fictional district-level example, not observed data. Each row represents one district in one reporting year; facility_count counts public libraries.

area_code	area_name	geographic_level	reporting_year	boundary_vintage	facility_count
001	North District	district	2025	2020	12
002	South District	district	2025	2020	8

In the accompanying notes, define the code system and jurisdiction, explain that boundary_vintage identifies the boundary edition used, and specify what qualifies as a public library. For a real release, include the source URL, retrieval date and any exclusions.

This structure lets readers compare counts without guessing what a row means. The area code can link the statistics to a matching boundary dataset. If you add more reporting years, the area code will repeat: within this example’s jurisdiction and boundary edition, use area_code plus reporting_year to identify each statistical row.

2. Keep place codes as text

Names help readers; codes help match records. Preserve both.

For U.S. Census data, GEOIDs identify geographic entities and support joins between statistical data and geographic files. A full county code combines the two-digit state code and three-digit county code: the county component alone is not nationally unique. See the Census Bureau’s GEOID structures and examples.

Treat identifiers as text, even when they contain only digits. Excel can remove leading zeros when it converts numerical text to numbers. Microsoft recommends setting identifier columns to Text during import. For publication, do not rely only on a cell’s visual number format. If zeros have already been lost, changing the column to Text will not restore them; recover the codes from the source or reconstruct them only from a documented code structure.

Before joining files:

• Confirm that both keys use the same code system, geographic level and boundary vintage.
• Check their documented lengths and preserve leading zeros.
• Inspect prefixes rather than stripping them automatically. A Census download’s GEO.ID, such as 0500000US48201, is not the same representation as the TIGER/Line county GEOID 48201.
• List unmatched codes and check duplicate keys against the intended row structure. Multiple years of statistics can legitimately share an area code; the matching boundary table should have one record per area for the chosen edition.
• Check output row counts against the intended join. For a left join that adds one matching boundary record to each statistical row, the row count should stay unchanged. Also inspect known matches: an unchanged count alone does not prove that places were paired correctly.

3. Document coordinates—or leave them out

An area-statistics table does not need latitude and longitude simply because it is geographic. Add coordinates only when they serve a defined purpose.

For point data, use separately named columns such as longitude and latitude, and document the coordinate reference system—the system that gives those numbers their spatial meaning. Do not relabel projected x/y coordinates as longitude and latitude without transforming them.

If you create a companion GeoJSON file, RFC 7946 specifies WGS 84 coordinates in decimal degrees, with positions ordered longitude, latitude. Named spreadsheet columns avoid that ordering ambiguity.

Check coordinate signs and plot a small sample against known locations. Do not substitute zero for an unknown location, and record whether a point represents an entrance, an approximate address location or an area centroid. A centroid is a point, not the area’s boundary. Extra decimal places are not proof of positional accuracy; the GeoJSON standard explicitly separates coordinate digits from uncertainty.

4. Check boundaries before comparing years

A reporting year tells readers when a measurement applies. A boundary vintage tells them which version of the areas it uses. Keep those concepts separate.

Before calculating change over time, check whether the areas have split, merged or otherwise changed. The Census Bureau provides relationship files describing both geographic comparability over time and relationships between different geographic types.

A relationship file does not automatically make measurements comparable. If one old area overlaps several new areas, document the method used to redistribute values—or avoid publishing a misleading like-for-like comparison.

Also distinguish counts from rates. A district’s facility count answers a different question from facilities per 10,000 residents. Publish the denominator and its period when providing a rate. Explain blanks and suppressed values using a consistent missing-value policy.

5. Publish the reviewed table and its context

Create a release copy containing only information suitable for unrestricted public access. Exclude sensitive addresses, individual movement records and confidential locations; geographic precision can itself be sensitive. Check the source’s licence or terms to confirm that redistribution is permitted, and retain required attribution.

TablePage supports CSV, TSV, XLSX and XLS uploads and generates public dataset pages with filterable tables and shareable links. Upload the reviewed tabular file, rather than assuming a spatial file will become a map.

Keep the source, geographic definitions, units, boundary vintage and missing-value explanation with the release—for example, in the web page where you share or embed the dataset. Use a clear table caption and summary to explain its scope.

Before distributing the link, inspect the public page: compare its row count with the release file, check codes beginning with zero, verify a known measurement and confirm that missing values remain distinct from confirmed zeros.