Inspiration
Environmental data is abundant, but turning it into usable evidence is difficult. Animal tracking records, satellite imagery, rainfall measurements, and habitat observations live in separate repositories, use different formats, and describe different places and periods.
We built Dora to reduce the distance between an ecological question and a reproducible answer. Our inspiration was a unified workspace where conservationists, researchers, and land managers could discover data, combine it correctly, and explore results without rebuilding a geospatial pipeline for every question.
What it does
Dora connects a conversational assistant with an interactive map, timeline, tables, and charts. Users can retrieve supported ecological datasets, inspect their coverage, and run historical analyses while retaining links to the underlying sources.
The technically interesting part happens between discovery and visualization: Dora prepares different datasets into a shared analytical structure, checks whether their relationships are valid, and passes the resulting evidence to an analysis engine.
How we built it
We divided the backend into four stages: Fetch, Normalize, Recipe, and Analysis. Python handles retrieval and analysis, PostgreSQL and PostGIS handle structured and spatial data, and TypeScript, Leaflet, and Vite power the workspace.
Aggregating datasets into meaningful observations
Combining environmental data requires more than collecting files. Each source has its own measurement structure: GPS fixes may arrive several times a day, rainfall represents an accumulation over an interval, and satellite vegetation measurements may represent multi-day composites.
Dora makes the meaning of each output row explicit. Depending on the question, a prepared table might contain one row per animal per day or one row per site per month. Sources are filtered and aggregated to the appropriate level before analysis.
For daily movement, we retain the last valid GPS fix for each animal on each UTC day and calculate displacement between consecutive days. If a day is missing, displacement remains unknown. This prevents missing tracking data from appearing as an animal standing still.
The same principle applies to environmental measurements: an unavailable rainfall measurement must remain distinct from a measured rainfall total of zero.
A validated spatial and temporal joining system
The Recipe system describes how datasets should be combined through a typed sequence of operations. It supports filtering, grouped aggregation, equality joins, spatial matching, preceding-observation matching, and rainfall aggregation over preceding intervals.
For example, connecting animal observations to environmental context requires answering several questions:
- Which environmental cell contains the animal’s location?
- Which measurement applies at the observation time?
- Is that measurement too old?
- Does the requested window contain sufficient coverage?
- Could multiple matches duplicate the animal observation?
Dora checks these relationships explicitly. Equality joins declare their expected cardinality, spatial joins resolve overlapping matches through stable rules, and temporal joins enforce tolerances. Window aggregations check interval overlap and measurement coverage.
Validated recipes compile into parameterized SQL and PostGIS operations. The planner works within an approved operation set, and execution checks the resulting table before publishing it.
Each prepared artifact includes dataset versions, recipe references, column meanings, units, missingness, and preparation context. Repeated requests can reuse compatible artifacts, while changes to inputs or recipe parameters produce a different cache identity.
Analysis grounded in prepared evidence
The Analysis stage consumes the prepared feature table and checks whether it supports the requested method. Historical analyses include movement summaries, revisit patterns, environmental comparisons, and time spent in areas with different vegetation conditions.
One example is residence-time analysis. Counting GPS points can distort results when tracking frequency varies. Dora instead uses elapsed time between valid observations, excludes long tracking gaps, and checks whether matched vegetation measurements remain applicable. The result describes observed animal-hours and time allocation, with excluded durations reported.
We also implemented bounded forecasting components for targets such as next-day displacement and cell use. These compare models against simple baselines using later observations held out for evaluation. However, integrated forecasting currently returns insufficient data until the preparation pipeline can guarantee when each predictor was available. Historical analysis is the current end-to-end capability.
Why this is impressive
Dora brings together several tasks that usually require separate tools and substantial manual work: discovering datasets, standardizing measurements, aligning them across space and time, preparing analysis tables, and presenting findings with provenance.
The central achievement is the validated path from heterogeneous observations to an interpretable result. A map can display two datasets together without establishing that they can be analyzed together. Dora checks the units, timing, spatial relationships, row structure, and coverage needed to make that combination meaningful.
This is what makes the Databricks analogy useful: Dora aims to give environmental researchers a unified data workflow, with ecological measurement rules built into preparation and analysis.
Challenges we faced
Our hardest challenge was reconciling datasets that describe the world at different resolutions. A GPS point, a rainfall interval, and a satellite composite cannot be joined correctly through matching column names alone.
We also had to prevent duplicate joins from inflating results, preserve missing values, handle gaps in tracking, and maintain clear contracts between independently developed pipeline stages.
Forecasting exposed another important challenge: a measurement’s timestamp does not necessarily tell us when it became available. A credible backtest must reproduce the information available at prediction time.
What we learned
We learned that trustworthy ecological analysis starts with the structure and meaning of the data. A sophisticated model cannot repair an invalid join, ambiguous unit, or misleading treatment of missing observations.
We also learned how to divide responsibility between AI and application code. AI helps interpret questions and navigate workflows; typed contracts, database operations, and analysis code provide the checks and calculations that make the results reproducible
Built With
- conversational-ai
- data-pipelines
- dataset-aggregation
- docker
- docker-compose
- environmental
- etl
- geojson
- geospatial-analysis
- gliclass
- json-schema
- leaflet.js
- machine-learning
- openai-api
- parquet
- postgis
- postgresql
- python
- rest-apis
- scikit-learn
- spatial-joins
- sql
- time-series-analysis
- typescript
- vite
Log in or sign up for Devpost to join the conversation.