BCGW Project Export

BCGW Project Export

DataBC pulls a CSV of published EPIC projects into the B.C. Geographic Warehouse (BCGW), where it becomes a mappable provincial layer. The pull is the only consumer: no EPIC page links the export, and no EPIC job produces it.

Direction

BCGW calls EPIC. EPIC does not push, and runs no scheduled job for this export. The schedule lives on the DataBC side and is not visible from EPIC, so a broken export shows up as a stale provincial layer rather than as a failure in any EPIC log.

flowchart LR
    DataBC["DataBC / BCGW"] -->|"GET /api/reports?type=bcgw"| RProxy["eao-nginx"]
    RProxy --> API["eagle-api"]
    API --> View[("read_only__reports__project_info")]
    Cron["eagle-cron-hot<br/>every 30 min"] --> View

Loading

Endpoint

Field	Value
URL	https://projects.eao.gov.bc.ca/api/reports?type=bcgw
Method	GET
Authentication	None. The route is public.
Response	text/csv, Content-Disposition: attachment; filename=export_bcgw.csv
Rate limit	200 requests per 60 seconds, shared with the rest of /api
Size	358 rows, 208,860 bytes (measured 2026-08-27)

type is required. Any value other than bcgw returns 400.

Columns

One row per published project, in this order.

Column	Source field
Latitude	centroid[1]
Longitude	centroid[0]
Project name	name
Proponent	proponent
Type	type
Sub-Type	subType
Description	description
MOE Region	region
Project Phase	currentPhaseName
Legislation	legislation
Federal Involvement	IAACInvolvement
EA Decision	eaDecision
Decision Date	eaDecisionDate, formatted MM-dd-yyyy
URL to Epic Project	https://projects.eao.gov.bc.ca/p/<_id>/project-details
Project GUID	_id

Column names are the contract with DataBC. Renaming or reordering one breaks their ingest.

Where the data comes from

The export reads the MongoDB collection read_only__reports__project_info, filtered to published: true. It never queries the Project collection directly, so the CSV is only as fresh as that materialized view.

The view is a hot view, rebuilt by the OpenShift CronJob eagle-cron-hot on */30 * * * *. Worst-case staleness is therefore about 30 minutes behind MongoDB, plus whatever interval DataBC polls on.

Piece	Where
Route definition	eagle-api/api/swagger/swagger.yaml, path /reports
Controller	eagle-api/api/controllers/report.js, publicGet
CSV builder	eagle-api/api/helpers/reports.js, createBcgwReport
View builder	eagle-api/api/materialized_views/reports/projectInfo.js
View schedule	eagle-api/helm/eagle-api/values.yaml, cronJobs.jobs[eagle-cron-hot]
Smoke test	eagle-api/test/smoke/public-other.test.js

Each request rebuilds the CSV: it queries the view, writes /tmp/export-bcgw-<timestamp>.csv, sends the file and deletes it. Nothing is cached on disk between calls.

Monitoring

An Application Insights availability test, eagle-bcgw-availability-prod, probes the production URL every 15 minutes from five locations. It passes only on HTTP 200 with /project-details in the body, which means at least one data row was written — a header-only CSV fails. It is defined in eagle-edge/azure/modules/availability.bicep and lives beside the eagle-public availability test in rg-eagle-public-prod.

Alerting is armed only when AVAILABILITY_ALERT_EMAIL is set on the eagle-edge prod GitHub environment. With it empty the test records results and notifies nobody.

No availability test sees stale data. If eagle-cron-hot stops, the export keeps returning 200 with the last built rows and every probe passes. The DEMI admin panel's Uptime screen shows the age of the source view for this reason: it reads GET /api/materialized-views/status and reports the export as Current, Stale or Build failed. Check eagle-cron-hot in 6cdc9e-prod, or the mat_view_hot document in the _system_locks collection, when the data looks old.

Related

• API Architecture - eagle-api structure
• Helm Charts - CronJob configuration
• Azure Hosting - Front Door and the availability tests