How to Prepare Related Sets of Data for Publication

Suppose you have three spreadsheets: park visits for 2024, park visits for 2025, and a directory of park names. You want one public table readers can filter by park and year—not three files they must reconcile themselves.

Sets of data are collections of related values, often called datasets. In a spreadsheet, their useful structure depends on what each row represents. Before combining files, decide whether you need to add more observations, attach more information to existing observations, or keep different kinds of records separate.

Choose the operation by what a row means

Write one sentence for each input: “One row represents ___.” That is its grain, or level of detail.

The tidyr guide to tidy data distinguishes variables from observations and recommends one variable per column, one observation per row and one value per cell. Use that structure as a starting point for your publication file.

Relationship between the sets of data	Action	Example
Same row meaning and compatible columns	Append: stack the rows	Add 2025 park-year visits below 2024 park-year visits
Extra attributes for records identified by a shared key	Join: match records and add columns	Attach a park name using park_id
Different row meanings without a defined summary rule	Keep separate	Park-year visit totals and individual maintenance events

A key is a column, or combination of columns, used to identify or match records. Matching column labels are not enough. Two columns named visits might count different things. Check definitions, units, reporting periods and geographic coverage before treating them as comparable.

Worked example: two annual files and a directory

These are fictional sample values, not reported park statistics.

Assume each annual file contains two rows, one per park, with columns park_id, year and visits. The directory contains one row per park_id, with its corresponding park_name.

Add a source_file column to each annual file containing its filename, then append the annual files. Join the directory by park_id using a left join: keep every row in the combined visits table and attach the matching name where available. The intended publication table is:

park_id	park_name	year	visits	source_file
P01	North Park	2024	100	visits_2024.csv
P02	River Park	2024	80	visits_2024.csv
P01	North Park	2025	120	visits_2025.csv
P02	River Park	2025	90	visits_2025.csv

Keep year in a column rather than relying on the original filename. Retain a source identifier so a reader—or your future self—can trace each observation.

For this example, park_id plus year should uniquely identify a row. park_id alone should be unique in the directory. A repeated park ID in the visits table is expected; a repeated park-year combination needs investigation. Resolve missing key values before joining.

Check that combining did not change the evidence

Record the input row counts and visit totals before editing. Then check:

• After appending: two rows plus two rows should produce four rows, assuming no exclusions or duplicate removal.
• After attaching names: a left join to a directory with unique park IDs should retain all four visit rows. List any unmatched IDs rather than silently dropping them.
• After both operations: visit totals should remain 180 for 2024 and 210 for 2025—390 overall—and every park-year key should still be unique.

Duplicate matching keys can multiply records. The pandas merging guide explains that a many-to-many join produces every matching combination when a key repeats in both tables. For example, two visit rows and three directory rows for the same park would produce six joined rows.

Do not fix that by deleting duplicates blindly. Determine whether the directory contains outdated names, multiple entrances or another legitimate distinction that requires a different key.

If you also have maintenance events, keep that event-level table separate—or explicitly summarize it to park-year before joining. Adding annual visits to every maintenance-event row would repeat those totals and make later sums misleading.

Publish the reviewed table with its context

Before uploading, check reuse terms and remove sensitive or restricted information. Public publication is not an appropriate way to share confidential records.

Prepare a short description alongside the table:

Sample park visits, 2024–2025. Each row represents one park in one calendar year. visits counts recorded visits, not unique visitors. Park names come from the accompanying directory. Values are fictional and provided only to illustrate the table structure.

For a real dataset, replace the sample note with the original source links, measurement definitions, missing-value rules, retrieval date and any exclusions. Include the directory source as well as the annual files, and explain whether names reflect current labels or historical ones.

As of October 2026, TablePage supports CSV, TSV, XLSX and XLS uploads and generates a public dataset page with a shareable link and filterable table. Upload only the reviewed publication file, then inspect the page: verify the four expected rows, check labels and values, and filter by one park to confirm both years appear.

If you choose CSV, use the CSV conversion checks before uploading. For the accompanying description, the guide to data table captions and summaries explains how to make row meanings, units and missing values clear to readers.