Skip to content
Menu

Look

Language

GitHub — @IchiSieben
Projects

Atlas Botánico del Perú

Live usable

I turned raw GBIF data into a tree of Peru's 21,585 accepted plant species that opens in the browser.

21,585 plant and 1,802 fungal species recorded in Peru, resolved against Kew's accepted-name backbone and broken down by department. A navigable taxonomic tree shows where diversity concentrates.

Technology

  • Data viz
  • ETL & databases
  • Scraping

Sector

  • Science & bioinformatics

Problem

Peru's plant and fungal diversity is scattered across GBIF, WCVP and APG IV with no single, synonym-resolved view. Raw occurrence counts overstate diversity because they never collapse different names for the same accepted species before counting.

Approach

A reproducible ETL over GBIF, WCVP and APG IV → static marts → a backend-free site. Synonyms get resolved before anything gets counted — which is why the figures come out lower, and more defensible, than sources that count raw names.

The pipeline runs ten reproducible stages over roughly 1.3 million raw GBIF occurrence records (1.29 million for Plantae alone): download, taxonomic matching against WCVP’s accepted-name backbone for plants and Index Fungorum’s backbone for fungi, modeling, aggregation, analysis, export and a data-quality profile. Every download is DOI-stamped, so any figure on the site traces back to an exact, citable snapshot rather than a live query that could silently change.

Matching against an accepted-name backbone is the actual work: raw GBIF records include synonyms, misspellings and outdated names, and none of those should be counted as a distinct species. After matching, 99.9% of plant occurrences and 98.75% of fungal occurrences resolve to an accepted name — the unresolved remainder is reported rather than silently dropped or folded into the total.

The eight resulting marts (richness by department, family composition, lifeform spectrum, described-per-year, and more) are plain JSON and Parquet files read at build time with a direct readFileSync, so the published site issues zero runtime fetches and needs no backend or database server to serve a navigable taxonomic tree and department choropleth.

Result

accepted plant species
21,585

data/exports/mart_kpis.json

accepted fungal species
1,802

data/exports/mart_kpis.json

GBIF plant occurrences processed
1,287,722records

data/exports/mart_kpis.json

Standards

Software quality (ISO/IEC 25010) Not run through a formal ISO/IEC 25010 checklist. Pipeline stages are ordered so exports are byte-for-byte stable across reruns (README), which is the maintainability property that mattered here.
Web performance (Core Web Vitals) not measured
Accessibility (WCAG 2.2) not measured
Research software (FAIR4RS) Findable: every GBIF download is DOI-stamped (Plantae 10.15468/dl.x4m2bc, Fungi 10.15468/dl.uh7bd4). Accessible: exports published as JSON/Parquet. Reusable: MIT-licensed code, documented .env.example for credentials.
Security hygiene The GBIF credential lives only in a local .env; .env.example was emptied and .gitignore covers .env before the repo's first commit.
Reproducibility uv-managed environment; the ten-stage pipeline (download → match → match_fungi → model → aggregate → analyze → export → profile) reruns end to end via `atlas data --full`, with a sample mode for a fast pass without credentials.
Benchmark methodology no benchmark claimed
Data / model documentation n/a — not a trained model
Versioning & change log MIT license; no CHANGELOG (pre-first-commit as of this pass).

What I'd do next

  • Version-control the repo (0 commits at this pass) with the GBIF credential scrubbed from .env.example first.
  • Apply the same ten-stage pipeline to Mar/ (marine species), its natural sibling in the local workspace.
  • Add a per-family drill-down to the taxonomic tree beyond department-level aggregation.