Home
Medium size project - duration 175 hrs
Project Mentor: Massimiliano Cannata, Daniele Strigaro, Claudio Primerano
istSOS already ships a powerful backend for time-travel and versioning, covering dedicated models for Things, Sensors, Datastreams, Observations, Locations, Features of Interest, Networks, and the Commit entity, together with versioning-aware SQL schemas and a tutorial notebook. However, these capabilities remain invisible to users who rely on the web administration interface.
This project bridges that gap. By extending the istSOS web administration UI with a full graphical time-travel experience, users will be able to select a specific instant or a time interval, view the historical state of any SensorThings entity exactly as it existed at that moment, and trace how it evolved over time through a Commit history viewer — all without writing a single API query by hand.
The result will be a richer, more transparent platform for environmental scientists, institutional operators, and data managers who need reproducible, auditable access to historical sensor data.
Transparent Historical Access: Any user regardless of API expertise will be able to inspect how a resource looked at any point in the past through a point-and-click interface. This dramatically lowers the barrier to historical data access.
Reproducible Scientific Workflows: Researchers and analysts can recover the exact state of observations, sensors, and datastreams as they existed at a specific past moment, improving reproducibility and making datasets citable and auditable.
Easier Data Governance and Auditing: Commit history and version browsing give administrators and data stewards clear visibility into who changed what, when, and why — crucial for collaborative or regulated deployments.
Accessibility for Non-Technical Users: Environmental agencies, research institutions, and field operators often lack the technical background to construct raw API requests. A graphical interface makes advanced temporal queries available to this wider audience.
Long-Term Strategic Value for istSOS: Making versioned data access a first-class, visible feature of the UI positions istSOS more strongly against other sensor data platforms and increases its appeal to institutions that require traceability as a compliance requirement.
Currently, managing istSOS SensorThings API components requires manual API interactions. This project will provide a more intuitive and efficient way to administer istSOS instances, making sensor registration and monitoring more accessible and user-friendly for a broader audience.
| Phase | Duration | Key Activities | Hours |
|---|---|---|---|
| Community Bonding (Pre-Coding) | May 1 – May 24 (~2 weeks) | Deep-dive into the existing traveltime models, versioning schema SQL, and traveltime.ipynb tutorials. Identify exact API endpoints for as_of and from_to parameters. Audit which entity types have full backend support vs. gaps. Set up local dev environment. Agree on UI mockups with mentors. |
— |
| Coding Phase 1 (Weeks 1–4) | May 25 – June 21 | Design and implement the time-selection UI components (single-instant and range pickers). Build the frontend query mapping service. Integrate time-travel parameters into the API call layer for Things and Sensors. Add initial historical data view panels for these two entities. | ~55 hrs |
| Coding Phase 1 (Weeks 5–6) | June 22 – July 6 | Extend historical entity viewer to cover Datastreams, Observations, Locations, and remaining entities. Wire up real API calls and handle edge cases (empty history, large datasets, pagination). Prepare midterm demo. | ~30 hrs |
| Midterm Evaluation | — | Working prototype: time-selection UI functional, historical views for all main entities operational, query mapping layer complete. Demo submitted to mentors. | — |
| Coding Phase 2 (Weeks 7–9) | July 7 – July 26 | Implement the Commit History Viewer: browse commits per entity, display author/timestamp/action/message, clickable commit-to-snapshot navigation. Add current vs. historical comparison layout. Refine UX, improve error messaging and empty states. | ~55 hrs |
| Coding Phase 2 (Weeks 10–11) | July 27 – August 15 | Backend gap closure (if any endpoints are missing or inconsistent). Write frontend unit tests and API integration tests. Fix bugs from testing. Performance review for large historical datasets. | ~25 hrs |
| Final Phase (Week 12) | August 17 – August 24 | Finalize all documentation: user-facing guide, developer notes, code comments. Final code cleanup, PR review with mentors, release notes. Prepare and submit final evaluation demo. | ~10 hrs |