What should I decide before a GIS project starts?

Lock the project CRS, the working data formats, the storage model (GeoPackage or PostGIS), a folder and naming convention, and the reproducibility approach before any data is imported. Retrofitting these mid-project is expensive and error-prone.

How do I choose the project CRS up front?

Pick a projected CRS suited to the area and the measurements you need, usually the local UTM zone or a national grid, and record its EPSG code. Reproject incoming data into it on ingest rather than mixing CRSs in the working store.

What folder and naming structure should a GIS project use?

Separate raw (read-only), derived, scripts and delivery folders, with lowercase, underscore-separated, date-stamped names. The goal is that anyone can tell at a glance what is source data and what was computed.

How do I make a GIS project reproducible from day one?

Keep raw inputs immutable, script the processing with GDAL or PyQGIS, store the scripts in Git, and write a manifest recording every source's origin, date, CRS and licence.

GIS Stack Checklist Before a Project Starts

The short answer

The decisions that are cheap to make before a project starts and ruinous to change halfway through are: the project CRS, the working data formats, the storage model, the folder and naming convention, and the reproducibility plan. Settle these in the first hour, write them into a short project README, and every later step inherits a stable foundation. Skip them and you spend the project firefighting misaligned layers, truncated fields, and deliverables nobody can rebuild.

This is a pre-kickoff checklist, not an analysis guide. It exists because most GIS failures are not analytical mistakes; they are decisions that were never made, so each analyst made a different one.

1. Lock the coordinate reference system

Choose one projected CRS for all measurement and analysis, and record its EPSG code in the README. The choice follows the area and the work:

Single small site or corridor: the local UTM zone (for example EPSG:32631 for WGS84 / UTM 31N, or EPSG:25831 for the ETRS89 variant used across much of Europe) gives metric coordinates and low distortion.
National extent: the national grid (British National Grid EPSG:27700, Lambert-93 EPSG:2154, and so on), because clients and reference data already use it.
Web delivery only: you will end up in EPSG:3857 for tiles, but do the analysis in a proper projected CRS first and reproject for display.

Decide the rule now: everything is reprojected into the project CRS on ingest. Mixing CRSs in the working store is the single most common cause of layers that do not line up. Verify each incoming layer's native CRS before transforming, because a wrong or missing source CRS produces a confident-looking but wrong result.

2. Fix the working data formats

State explicitly which formats are working formats and which are merely exchange formats.

Working vector: GeoPackage (.gpkg) for solo project files, PostGIS for shared/large data.
Working raster: Cloud-Optimized GeoTIFF or tiled, compressed GeoTIFF (-co TILED=YES -co COMPRESS=DEFLATE) with overviews.
Exchange only: shapefiles and CSVs you receive or must deliver, never your internal store. The shapefile's 10-character field limit and 2 GB ceiling cause silent truncation and data loss.

Writing this down stops the slow drift where one analyst quietly starts editing a shapefile on a shared drive.

3. Choose the storage model

Decide where the authoritative data lives before importing anything:

GeoPackage when one person owns the project. A single file, multiple layers, embedded styles, no sidecar sprawl.
PostGIS when more than one person edits the same layers, when datasets are large, or when you need server-side queries and indexing. Set SRIDs explicitly with ST_SetSRID and reproject with ST_Transform so geometries never carry the wrong SRID.

Make the call up front because migrating a live project from scattered files into PostGIS mid-stream is far more painful than starting there.

4. Define folders and naming

Agree a layout so source and computed data are never confused:

project/
  raw/        # immutable inputs, read-only
  derived/    # everything you compute (project.gpkg, rasters)
  scripts/    # GDAL/PyQGIS/SQL that build derived from raw
  delivery/   # client outputs
  MANIFEST.md
  README.md

Use lowercase, underscore-separated names, and date-stamp anything versioned (constraints_v2_20260326.gpkg). Mark raw/ read-only at the filesystem level so processing must produce a new derived layer rather than overwriting source. This convention is what lets a reviewer tell, a year later, what was measured versus what was assumed.

5. Plan reproducibility before data lands

The test you are designing for is: can someone rebuild every deliverable from raw/ plus scripts/? To make that true from day one:

Initialise a Git repo for scripts/, styles, and SQL (not the large rasters).
Write a manifest entry for every source as it arrives: where it came from, the download date, its native CRS, and its licence.
Script the ingest. Even the first reprojection should be a committed command, for example:

gdalwarp -t_srs EPSG:25831 -tr 10 10 -r bilinear \
  -co TILED=YES -co COMPRESS=DEFLATE \
  raw/national_dem.tif derived/dem_25831.tif

ogr2ogr -f GPKG -t_srs EPSG:25831 \
  derived/project.gpkg raw/parcels.shp -nln parcels

A 15-minute kickoff worked example

A team starts a flood-constraint study for a district.

CRS: the district sits in one UTM zone, so they pick EPSG:25831 and note it in the README.
Formats: GeoPackage for vectors, COG for the DEM; client shapefiles flagged as exchange-only.
Storage: two analysts will co-edit the constraints layer, so that one layer goes to PostGIS; the rest stays in derived/project.gpkg.
Naming: they create the folder skeleton and set raw/ read-only.
Reproducibility: git init, a MANIFEST.md stub, and scripts/01_ingest.sh with the two commands above committed before any analysis begins.

Fifteen minutes spent here removes the most common mid-project failures.

Common pitfalls and why they happen

No agreed CRS. Each analyst loads data in its native CRS; on-the-fly reprojection hides the mismatch until a measurement or overlay is wrong. The fix is a written project CRS and reproject-on-ingest.
Editing exchange formats in place. Shapefiles get edited on a shared drive, fields truncate, and concurrent edits corrupt the file. It happens because the format was never declared exchange-only.
Deferring the storage decision. Starting in files and "moving to a database later" rarely happens cleanly; the migration is deferred until a deadline forces it.
Undocumented sources. Without a manifest, the provenance of a layer is lost the moment the person who downloaded it forgets. Record it at ingest, not later.

Validating the checklist

Before kickoff is "done," confirm: the README names the project CRS with its EPSG code; the folder skeleton exists with raw/ read-only; the Git repo is initialised with at least one ingest script committed; and a second team member can clone the repo and run the ingest against the raw inputs successfully.

Bathyl perspective

We treat the first hour of a project as infrastructure, not overhead. Locking the CRS, formats, storage, naming, and reproducibility before data arrives is the cheapest insurance available, because every later decision compounds on top of these. A project that starts with this checklist stays auditable; one that skips it accumulates quiet, expensive debt.