EIA Biodiversity R: Automate NEMA Inventory Tables

Build a single R tibble that drives all NEMA-mandated biodiversity annexes automatically: no copy-paste, no midnight reformatting, no review rejections.

Keywords

NEMA biodiversity inventory, EIA reproducibility, environmental analytics Kenya, R Markdown EIA report, EMCA compliance

It is 1:47 am the night before your NEMA submission and you are rebuilding the Species Inventory Annex because a field team updated their transect counts after you had already formatted the table. The new data changes three species totals, which means the richness summary in Chapter 4 is now wrong, the IUCN threat-status flag in Annex C still references the old count, and the species accumulation figure no longer matches either. You are not making an analytical error. You are paying the price for a workflow that treats biodiversity data as a formatting problem rather than a data problem.

This post is about fixing that workflow. The fix is a single canonical R tibble that holds all field biodiversity data, with every NEMA-required annex table, every richness metric, and every threat-status flag derived automatically from that one source. When field data changes, you re-render. The entire annex regenerates in under two minutes.

What NEMA Actually Requires

Kenya’s Environmental Impact Assessment and Audit Regulations (Legal Notice 101 of 2003, with subsequent amendments under EMCA) require a biodiversity baseline in every EIA study report. The regulations specify that the report must include a flora and fauna inventory, a description of habitat types, identification of rare or endangered species, and a statement on endemism.

What the regulations do not specify is any data format, column structure, or table layout. Every firm invents its own annex template. A NEMA review officer seeing your report may have reviewed three other EIAs that week, each with a completely different table structure. Inconsistencies between your species count in the narrative and the total in the annex are easy to introduce and easy for a reviewer to spot.

The practical requirement, inferred from review rejections and NEMA guidance notes, is: a complete species inventory with family and order, a habitat association column, IUCN Red List category for each species, a flag for endemic or near-endemic taxa, and observation counts or presence-absence by survey zone. That structure maps directly to a tidy R tibble.

Designing the Canonical Tibble

The data model is the foundation. Every downstream table, summary, and figure reads from this one object. The columns that matter for NEMA compliance are:

library(dplyr)
library(tibble)

# Minimal canonical schema for NEMA biodiversity inventory
species_data <- tibble(
  # Taxonomy
  species        = character(),   # Accepted binomial
  common_name    = character(),
  family         = character(),
  order          = character(),
  class          = character(),   # Aves, Mammalia, Reptilia, etc.

  # Spatial and habitat context
  habitat        = character(),   # Riparian, Savanna, Woodland, etc.
  survey_zone    = character(),   # e.g. "Zone A – Project Footprint"
  observation_count = integer(),
  detection_method = character(), # Transect, Mist-net, Camera-trap, etc.

  # Conservation status
  iucn_category  = character(),   # LC, NT, VU, EN, CR, EW, EX, DD, NE
  cites_appendix = character(),   # I, II, III, or NA
  endemic        = logical(),     # TRUE if Kenya endemic or near-endemic
  protected_under_wcma = logical(), # Wildlife Conservation & Management Act

  # Data provenance
  observer       = character(),
  survey_date    = as.Date(character()),
  record_id      = character()    # Unique key for each observation event
)

Build this once per project, populate it from your field datasheets, and never touch it manually again. If a field team revises their counts, they edit the source CSV. The tibble reads from that CSV. Every downstream product regenerates.

For actual project use, read the canonical tibble from a version-controlled CSV:

species_data <- readr::read_csv(
  "data/raw/biodiversity_field_records.csv",
  col_types = readr::cols(
    survey_date = readr::col_date(format = "%Y-%m-%d"),
    endemic = readr::col_logical(),
    protected_under_wcma = readr::col_logical(),
    observation_count = readr::col_integer()
  )
)

IUCN Red List Status: Lookup Without Manual Copying

Manually typing IUCN categories is where errors accumulate fastest. The rredlist package provides programmatic access to the IUCN Red List API. For field projects in Kenya, you typically work with a bounded species list, so a cached lookup makes more sense than live API calls during report rendering.

library(rredlist)

# One-time lookup: run this when species list is finalised
# Requires IUCN_REDLIST_KEY environment variable
fetch_iucn_status <- function(species_list, cache_path = "data/iucn_cache.rds") {

  if (file.exists(cache_path)) {
    return(readRDS(cache_path))
  }

  results <- purrr::map_dfr(species_list, function(sp) {
    resp <- tryCatch(
      rl_search(name = sp)$result,
      error = function(e) NULL
    )
    if (is.null(resp) || nrow(resp) == 0) {
      return(tibble(species = sp, iucn_category = "NE", iucn_id = NA_integer_))
    }
    tibble(
      species       = sp,
      iucn_category = resp$category[1],
      iucn_id       = resp$taxonid[1]
    )
  })

  saveRDS(results, cache_path)
  results
}

iucn_lookup <- fetch_iucn_status(unique(species_data$species))

# Join back to canonical tibble
species_data <- species_data |>
  select(-iucn_category) |>
  left_join(iucn_lookup, by = "species")

The cache at data/iucn_cache.rds persists across renders. When the IUCN updates a species’ status, you delete the cache file, re-run once, and the new status propagates to every table automatically. This approach also works offline once the cache exists, which matters on field trips with intermittent connectivity.

For projects where the species list is stable and well-known, a hand-curated lookup table stored as a CSV in data/reference/iucn_status.csv is a legitimate alternative. The critical point is that the status column in your canonical tibble is always derived, never typed by hand into the annex.

Species Richness and Diversity Indices

NEMA reviewers expect a summary of species richness by taxonomic group and habitat. Diversity indices (Shannon-Wiener and Simpson) add methodological weight and are standard in peer-reviewed baseline assessments across Kenya’s infrastructure corridor projects.

library(vegan)

# Species richness by class and habitat
richness_summary <- species_data |>
  group_by(class, habitat) |>
  summarise(
    species_richness = n_distinct(species),
    total_observations = sum(observation_count, na.rm = TRUE),
    threatened_spp = sum(iucn_category %in% c("VU", "EN", "CR"), na.rm = TRUE),
    endemic_spp = sum(endemic, na.rm = TRUE),
    .groups = "drop"
  ) |>
  arrange(class, desc(species_richness))

# Shannon-Wiener and Simpson indices per habitat
diversity_by_habitat <- species_data |>
  group_by(habitat, species) |>
  summarise(n = sum(observation_count, na.rm = TRUE), .groups = "drop") |>
  tidyr::pivot_wider(names_from = species, values_from = n, values_fill = 0) |>
  tibble::column_to_rownames("habitat") |>
  (\(m) {
    tibble(
      habitat  = rownames(m),
      H_shannon = vegan::diversity(m, index = "shannon"),
      D_simpson = vegan::diversity(m, index = "simpson"),
      S_richness = vegan::specnumber(m)
    )
  })()

The vegan package computes these indices from a species-by-site matrix. The pipeline above builds that matrix directly from the canonical tibble, so the indices update automatically when field data changes.

Generating the NEMA Annex Tables

The annex tables are where a reproducible workflow delivers the most visible return. A formatted knitr::kable() table with kableExtra styling produces output that matches what NEMA reviewers expect, derived entirely from the canonical tibble.

library(knitr)
library(kableExtra)

# Annex Table A: Complete Species Inventory
annex_inventory <- species_data |>
  arrange(class, order, family, species) |>
  mutate(
    iucn_display = case_when(
      iucn_category == "CR" ~ "CR*",
      iucn_category == "EN" ~ "EN*",
      iucn_category == "VU" ~ "VU*",
      TRUE ~ iucn_category
    ),
    endemic_display = if_else(endemic, "Yes", "No")
  ) |>
  select(
    `Class` = class,
    `Order` = order,
    `Family` = family,
    `Species` = species,
    `Common Name` = common_name,
    `Habitat` = habitat,
    `IUCN Status` = iucn_display,
    `Endemic` = endemic_display,
    `Detections` = observation_count,
    `Method` = detection_method
  )

annex_inventory |>
  kable(
    caption = paste0(
      "Annex A: Biodiversity Species Inventory: ",
      params$project_name,
      " (Survey Period: ", params$survey_period, ")"
    ),
    booktabs = TRUE,
    longtable = TRUE
  ) |>
  kable_styling(
    latex_options = c("repeat_header", "striped"),
    font_size = 9
  ) |>
  footnote(
    general = "* Threatened species (CR: Critically Endangered, EN: Endangered, VU: Vulnerable). IUCN Red List categories per IUCN (2024). Endemic status per Kenya Biodiversity Atlas.",
    threeparttable = TRUE
  )

A second table summarises richness and threat status, which typically appears in the main report body rather than the annex:

# Table in main report: Richness and threat status summary
richness_summary |>
  kable(
    col.names = c("Class", "Habitat", "Species Richness",
                  "Total Detections", "Threatened Spp.", "Endemic Spp."),
    caption = "Table 4.X: Species Richness and Conservation Status Summary by Taxonomic Class and Habitat Type",
    booktabs = TRUE
  ) |>
  kable_styling(latex_options = "striped") |>
  column_spec(5, bold = TRUE, color = "darkred")

Both tables are generated from the same object. If you change a field record in biodiversity_field_records.csv, both update on the next render.

Parameterising for Multi-Project Reuse

Kenya’s infrastructure pipeline means many consultancies run concurrent EIAs. The LAPSSET corridor alone involves environmental studies across Isiolo, Marsabit, and Lamu counties. SGR Phase 2 overlaps with sensitive savanna habitat across the Naivasha-Kisumu alignment. A single parameterised template handles all of them.

---
title: "Biodiversity Baseline Annex: `r params$project_name`"
subtitle: "NEMA Ref: `r params$nema_ref`"
format:
  pdf:
    toc: false
    number-sections: false
params:
  project_name: "Default Project"
  nema_ref: "NEMA/EIA/5/2/XXXX/XXX"
  survey_period: "Q1 2026"
  project_county: "Nairobi"
  project_coords: "1.2921° S, 36.8219° E"
  field_data_path: "data/raw/biodiversity_field_records.csv"
---

Render for each project from the command line:

quarto::quarto_render(
  input = "biodiversity_annex.qmd",
  execute_params = list(
    project_name    = "LAPSSET Port Access Road EIA",
    nema_ref        = "NEMA/EIA/5/2/2026/047",
    survey_period   = "Q4 2025",
    project_county  = "Lamu",
    project_coords  = "2.2717° S, 40.9020° E",
    field_data_path = "data/raw/lapsset_road_biodiversity.csv"
  ),
  output_file = "output/LAPSSET_biodiversity_annex_2026.pdf"
)

The template reads the field data from params$field_data_path, runs the IUCN lookup, computes richness, and renders the full annex. New project, new CSV, same template. The table structure stays consistent across submissions.

Cross-Checking Field Records Against GBIF

Field surveys have finite duration and effort. A useful quality control step is to cross-reference your inventory against GBIF occurrence records for the project area, flagging species present in GBIF that your survey did not record. This does not invalidate your baseline, but it documents the comparison and gives reviewers confidence that your team considered the broader evidence base.

library(rgbif)

# Pull GBIF records within project bounding box
gbif_crosscheck <- function(lat_centre, lon_centre, radius_km = 10) {
  occ_search(
    country     = "KE",
    decimalLatitude  = paste0(lat_centre - 0.1, ",", lat_centre + 0.1),
    decimalLongitude = paste0(lon_centre - 0.1, ",", lon_centre + 0.1),
    hasCoordinate = TRUE,
    limit = 5000
  )$data |>
    select(species, class, family, year, basisOfRecord) |>
    filter(!is.na(species), year >= 2015)
}

gbif_area <- gbif_crosscheck(lat_centre = -1.29, lon_centre = 36.82)

# Species in GBIF but not in field survey
gbif_only <- anti_join(
  gbif_area |> distinct(species),
  species_data |> distinct(species),
  by = "species"
)

The GBIF comparison belongs in the methods section, not the species inventory itself. Our earlier post on GBIF Kenya data quality covers the coordinate cleaning and taxonomic validation steps you should apply to this GBIF pull before using it as a cross-reference. Raw GBIF data without quality filtering will flag phantom species and undermine the comparison.

Project Structure for Biodiversity Annexes

A clean directory layout keeps the pipeline self-contained and legible to any colleague who picks it up:

project-eia-001/
├── biodiversity_annex.qmd       # Parameterised template
├── R/
│   ├── fetch_iucn_status.R      # Cached IUCN lookup function
│   ├── compute_richness.R       # Richness and diversity indices
│   └── build_annex_tables.R     # kable table builders
├── data/
│   ├── raw/
│   │   └── biodiversity_field_records.csv   # Source of truth: never edit directly
│   ├── reference/
│   │   └── iucn_cache.rds       # Cached IUCN API responses
│   └── processed/               # Outputs written by pipeline
└── output/                      # Rendered PDFs

The data/raw/ CSV is the only file field staff need to update. The R/ functions are testable in isolation. The iucn_cache.rds persists between renders. If you also run a {targets} pipeline for the full EIA (as described in our post on EIA reproducibility), the biodiversity tibble is one target in that pipeline, with the annex tables as downstream targets.

The Commercial Case

A single annex regeneration typically takes forty minutes of manual effort on a typical Kenyan EIA project: find the original data, update the relevant rows, reformat the table, check the column totals, update the summary statistics in the narrative, and check whether the threat-status flags are still correct. With the workflow above, the same update takes under two minutes.

Across four concurrent ASAL county screenings or three SGR-corridor EIAs running simultaneously, that difference compounds. The bigger cost, though, is the rejection risk. A NEMA review officer who finds a species count in Annex C that differs from Chapter 4 by even a small margin has grounds to return the report, and the revision clock restarts. The canonical tibble approach makes that class of error structurally impossible.

The data model, IUCN lookup, richness calculation, and parameterised output described here are the specific pieces that other posts in this series do not cover. The GBIF Kenya data quality post handles the upstream data sourcing. The broader pipeline and audit-trail approach are covered in ESIA reproducibility. This piece fills the gap: the biodiversity data model itself, and the code that turns it into compliant NEMA annex tables.

If your consultancy produces more than two EIAs per year and still assembles biodiversity annexes by hand, what is the cost of the next rejection?

---

Kwiz Computing Technologies provides environmental data science services for EIA and ESIA projects across East Africa. Contact us to discuss reproducible biodiversity baseline workflows for your NEMA submissions.