Short answer

In an environmental impact assessment (EIA), GIS does two jobs: it assembles a spatial baseline of the receiving environment, and it quantifies how a proposed project intersects that environment. The credible deliverables are not pretty maps but defensible numbers — area of habitat lost, length of watercourse crossed, number of dwellings within a noise contour, hectares within a viewshed. Get the coordinate system, buffer distances and layer provenance right, and the analysis survives scrutiny from a regulator or a public inquiry.

The single most common failure is measuring distance or area in a geographic CRS (degrees), which silently corrupts every buffer and every hectare figure in the report.

What an EIA actually needs from GIS

An EIA is structured around receptors (the things that can be harmed — people, designated habitats, watercourses, archaeology, soils, air) and impact pathways (how the project reaches them — direct land take, noise, dust, hydrological change, visual intrusion). GIS is the tool that turns vague concern into measured exposure.

A useful baseline is layered by theme rather than by source file:

  • Designations and constraints: protected areas, Natura 2000 / SSSI / equivalent designations, flood zones, groundwater source protection zones, mineral and waste safeguarding areas.
  • Ecology: habitat polygons (e.g. UK Hab / EUNIS classes), protected-species records, hedgerow and watercourse networks.
  • Physical environment: a DEM (Copernicus GLO-30 at 30 m, national lidar at 1–2 m where available), geology, soils, hydrology.
  • Human environment: residential receptors, public rights of way, land use, noise-sensitive premises.

Each layer carries metadata you will be asked about later: source, licence, capture date, scale or resolution, and the CRS it arrived in. Record these before you reproject anything.

Coordinate system discipline

Decide one project CRS and reproject everything into it on import. For metric work, use the appropriate national grid or UTM zone — for example EPSG:27700 (British National Grid), EPSG:2154 (RGF93 / Lambert-93, France), or the correct EPSG:326xx UTM zone — so that lengths come out in metres and areas in m². Web data and many open datasets arrive in EPSG:4326 (WGS84 geographic) or EPSG:3857 (Web Mercator); both are wrong for measurement. Web Mercator in particular inflates area badly away from the equator.

In QGIS, set the project CRS explicitly and enable on-the-fly reprojection, but still store each layer in the project CRS for analysis. To force it on the command line:

ogr2ogr -t_srs EPSG:27700 receptors_bng.gpkg receptors_wgs84.gpkg

In PostGIS, transform once and index the result:

ALTER TABLE receptors
  ALTER COLUMN geom TYPE geometry(MultiPolygon, 27700)
  USING ST_Transform(ST_SetSRID(geom, 4326), 27700);
CREATE INDEX receptors_geom_idx ON receptors USING GIST (geom);

Core analyses, with real steps

Constraint mapping and buffers

Buffers express setback distances and zones of influence. A pipeline screening might apply a 250 m buffer to designated sites and a 50 m buffer to watercourses; a quarry noise screen might use distance bands at 100, 250 and 500 m. In QGIS use Vector geometry → Buffer (algorithm native:buffer) or, on the command line:

ogr2ogr -dialect SQLite -sql \
  "SELECT ST_Buffer(geometry, 250) AS geometry FROM sssi" \
  sssi_buf250.gpkg sssi.gpkg

Because the layer is in metres, the value 250 means 250 m. The same number in EPSG:4326 would buffer by 250 degrees — a meaningless, planet-spanning ring.

Weighted sensitivity overlay

Combine constraints into a single sensitivity surface. Rasterise each constraint to a common grid (say 10 m), assign a sensitivity weight, and sum. With GDAL:

gdal_rasterize -burn 3 -tr 10 10 -a_nodata 0 -ot Byte habitats.gpkg habitats.tif
gdal_calc.py -A habitats.tif -B flood.tif -C protected.tif \
  --calc="A+B+C" --outfile=sensitivity.tif

Keep the weighting scheme explicit in the report — reviewers will challenge subjective weights, so document the rationale rather than burying it in a model.

Viewshed (landscape and visual impact)

For a wind turbine, mast or quarry face, compute a Zone of Theoretical Visibility. QGIS has the Viewshed Analysis plugin; GRASS provides r.viewshed; GDAL offers gdal_viewshed:

gdal_viewshed -ox 412300 -oy 285600 -oz 80 -md 10000 \
  dem.tif ztv.tif

Here -oz 80 is the observed object height (m above ground) and -md 10000 the maximum distance (m). Use a DEM that includes vegetation and buildings (a DSM) where screening matters, or the ZTV will overstate visibility.

Hydrology and catchments

To assess downstream water impacts, derive flow from the DEM. In QGIS/GRASS use r.watershed, or SAGA's Fill Sinks then Catchment Area. Delineate the catchment upstream of any discharge point and intersect it with the project footprint to estimate the contributing area affected.

Worked example: quantifying a land take

Suppose the project boundary is redline.gpkg and you need habitat loss by class. Intersect, then sum area:

SELECT h.habitat_class,
       ROUND(SUM(ST_Area(ST_Intersection(h.geom, r.geom)))::numeric, 0) AS m2_lost
FROM habitats h
JOIN redline r ON ST_Intersects(h.geom, r.geom)
GROUP BY h.habitat_class
ORDER BY m2_lost DESC;

Because geom is in a metric CRS, ST_Area returns m² directly. Convert to hectares (÷10,000) for the report table. This single query produces the habitat-loss figure that drives the ecology chapter and the compensation calculation.

Common pitfalls and why they happen

  • Measuring in degrees. A buffer or area run in EPSG:4326 is wrong because the unit is angular, not metric. Symptom: hectare totals that are absurdly large or small, or buffers that fail to render. Fix by reprojecting first.
  • Invalid geometries breaking overlays. Self-intersecting polygons make ST_Intersection fail or return slivers. Run ST_MakeValid (or QGIS Fix geometries) before any overlay.
  • Mixed DEM and DSM. Using a bare-earth DEM for a viewshed ignores screening by trees and buildings and overstates visual impact. Match the surface model to the question.
  • Sliver polygons after intersection. Tiny artefacts inflate feature counts. Filter by ST_Area < threshold or snap inputs to a common topology first.
  • Undocumented sensitivity weights. A weighted overlay with no written justification is the first thing a reviewer attacks. Tabulate weights and reasons.
  • Stale baseline data. Habitat and designation layers change; a species record from a decade ago may not reflect current conditions. Record capture dates and flag anything beyond the agreed currency window.

Validation and QA

  • Reproject a known control point and confirm it lands where it should before trusting bulk transforms.
  • Cross-check a sample of automated areas against manual measurement on the screen.
  • Run topology checks (overlaps, gaps, invalid geometry) on every digitised layer.
  • Re-run the whole pipeline from raw inputs and confirm the headline numbers are identical — if they drift, a step depends on hidden state.
  • Keep intermediate outputs (buffers, intersections, rasterised constraints) so a third party can reproduce each figure in the report.

Reproducibility

Regulators and inquiries can revisit an assessment years later. Build the analysis as a pipeline, not a sequence of clicks: capture it in the QGIS Graphical Modeler, a PyQGIS script, or SQL stored against PostGIS. A scripted pipeline lets you regenerate every figure when a single input is updated, and it documents exactly what was done — which is the difference between an assessment that holds up and one that has to be redone.

Bathyl perspective

We treat EIA spatial work as evidence, not illustration. The aim is a pipeline where every hectare and every buffer can be traced back to a dated source and a reproducible step, so the conclusions stand up when challenged rather than only when admired.

Related reading

Sources