Jegeo Replication Package

Replication Package (jegeo-replication-package)

When to trigger

• The analysis uses spatial data (shapefiles, geocoded points, raster, network ties) whose provenance and processing are not documented
• A referee asks "can this be reproduced?" and the answer is currently no
• You are deciding what to share given JEG's policy and any confidentiality constraints
• Spatial joins, projections, and unit-boundary versions were done interactively and are not scripted

What JEG actually requires (and what it does not)

JEG's data/code policy is encouragement-based and triggered after acceptance, not a mandatory pre-acceptance replication archive (检索于 2026-06；以官网为准). Authors are asked at acceptance whether associated data exist and whether they wish to publish them as supplementary material; ORCID is required at submission. This is a genuine point of difference from QE, AEJ, and the AEA journals, which run a Data Editor reproducibility check before acceptance.

The practical implication: at JEG you are not forced to deposit, but a credible, well-documented package is a strong signal and pre-empts the reproducibility objection. Build it as if it were required — referees increasingly expect it, and editors may ask — but understand the timing and the discretion the policy gives you.

Spatial data is the hard part

Replication in economic geography fails most often on the spatial steps, not the regressions. Document them explicitly:

Confidential and proprietary spatial data

• Geocoded firm or individual data are often confidential and cannot be posted. Provide instead: the derived analysis file where licensing allows, the full code, a synthetic or simulated example dataset so the code runs, and clear access instructions for the restricted source.
• Note any disclosure-avoidance steps (aggregation, rounding) so a reader understands what was changed and why.

Reproducibility tooling for spatial work

Spatial pipelines drift silently as upstream boundary files, projection libraries, and geocoding services change. Pin the moving parts:

• Record exact versions of the geospatial stack (e.g., GDAL/PROJ, sf/sp, geopandas, PostGIS) — a PROJ upgrade can shift distance calculations.
• Freeze and ship the boundary/shapefile actually used, or its exact source and vintage, rather than assuming a reader can re-download "the" boundaries.
• Set and report random seeds anywhere simulation, bootstrap, or Conley-cutoff resampling enters.
• Cache geocoding results (with match rates) so the pipeline does not silently re-query a changed external API.
• Where a containerized or environment-locked setup (Docker, renv, conda env) is feasible, include it — spatial dependencies are the ones most likely to break on another machine.

Package contents

• README mapping each table/figure/map to the script that produces it
• Raw → analysis data pipeline scripted end to end (no manual GIS steps)
• Spatial provenance documented (boundary vintage, CRS, geocoding, joins, W)
• Software environment recorded (package/GIS-library versions, seeds)
• Confidential data handled via derived file + synthetic example + access path
• A data-availability statement drafted for the post-acceptance step
• Code runs top-to-bottom on a clean machine and reproduces the headline numbers