Store every snapshot
Current availability is temporary. Keeping every update creates the historical record required for trend analysis and forecasting.
Engineering case study
Parking Switzerland
Platform
A production data platform that collects, enriches and predicts parking availability across multiple Swiss cities from heterogeneous public data sources.
5Swiss cities
88monitored parkings
~26,000parking spaces
Dailymodel retraining
01 — The challenge
Official websites only expose the current state.
Public parking operators generally publish only the current availability. Once that value changes, the previous state disappears.
Without historical data it is impossible to analyse behaviour, observe trends, estimate occupancy evolution, or predict future availability. The data needed for intelligence simply does not exist yet.
Existing city websites are fragmented too. Users must consult several city-specific interfaces independently instead of using one coherent view.
The objective was never to replace official city websites. Instead, the platform unlocks value from public data that was never intended to support historical analysis or forecasting.
The goal became a unified platform: not a collection of city websites, but a production data system that turns temporary public feeds into a structured historical database.
02 — The solution
Build the history before presenting the answer.
The website is only the presentation layer. The engineering value lies in the platform underneath it: connectors collect public updates, PostgreSQL preserves the history, enrichment adds context, and daily regression models turn accumulated observations into forecasts.
City-specific collection is deliberately separated from shared validation, storage, prediction and presentation. This keeps the system extensible as new Swiss cities and new public interfaces are added.
Production architecture
Public data sources
RSS · JSON · XML · Open Data
↓RSS · JSON · XML · Open Data
City-specific connectors
↓Validation & deduplication
↓Historical database
PostgreSQL
PostgreSQL
Data enrichment
Weather · weekday · season · occupancy
Weather · weekday · season · occupancy
Prediction engine
Parking-level regression models
Parking-level regression models
↓
Flask backend
↓Leaflet + OpenStreetMap UI
03 — Data pipeline
Every update becomes part of the system’s memory.
- 01
Public update published
A parking operator exposes a new RSS, JSON, XML or open-data record.
- 02
Connector retrieves it
The city-specific connector translates the source into the shared platform shape.
- 03
Validate & deduplicate
Freshness, completeness and duplicate observations are checked before storage.
- 04
Snapshot stored
The observation becomes a historical PostgreSQL record instead of replacing the previous value.
- 05
Enrich & recalculate
Weather and contextual variables are associated; trends and occupancy are updated.
- 06
Train & publish
Daily models retrain and the Flask application serves the newest data and forecasts.
The public interface updates as soon as the pipeline has processed a new observation. Model training remains an automated daily operation on top of the continuously growing history.
04 — Key engineering decisions
One model per parking
Each parking behaves differently. Independently trained models preserve local behaviour instead of hiding it inside one global average.
Enrich before prediction
Weather, weekday, weekend, season, occupancy percentage and historical evolution give a forecast more context than raw capacity alone.
Modular city connectors
Each city can expose a different interface. Adding a city means implementing its connector while reusing the backend, templates and interface.
05 — Historical database
The hardest part was creating the dataset that was missing.
Official providers expose live information, not a usable history. The platform continuously creates that history one validated snapshot at a time.
Every parking update is stored instead of overwritten. That simple decision changes the nature of the product: availability becomes an observable time series rather than a disposable number.
Once the historical database exists, it supports every advanced feature around it—trend analysis, occupancy evolution, behavioural analysis, forecasting, and future machine learning applications. The database is not an implementation detail; it is the product’s foundation.
Why historical data mattersOfficial website
↓Current availability
Parking Switzerland Platform
Current availability
+ Historical trends
+ Weather context
+ Forecasts
+ Behaviour analysis
06 — Prediction engine
Forecasts learn parking by parking.
Predictions are based on historical regression models. Every parking has its own independently trained model because each location has different capacity, usage patterns and local behaviour.
Railway stations, shopping districts, city centres and residential areas exhibit fundamentally different occupancy patterns. Independent models preserve these local behaviours better than a single global model.
Training occurs daily as new observations become available. Forecasts therefore evolve naturally as the historical dataset accumulates more evidence.
Newly added cities initially have lower prediction accuracy because their models have shorter historical datasets. Accuracy can improve organically as the platform continues collecting observations.
07 — User experience
A data-oriented interface for a live decision.
The interface was intentionally designed for users who want context, not only a single current number. Every parking combines current availability with occupation percentage, historical trends, forecast evolution, and a visible refresh timestamp.
An interactive Leaflet map built on OpenStreetMap provides geographic context, while a list view makes comparison and scanning fast. The website makes the platform legible; it does not replace the platform’s ingestion, history or prediction layers.
Open the official interface to explore current parking availability across Switzerland.
Visit findparking.ch ↗08 — Results
A production platform turning public feeds into shared intelligence.
The current deployment covers five Swiss cities, 88 monitored parkings and approximately 26,000 parking spaces. The historical database continues to grow as automated ingestion records new public observations.
Ingestion, enrichment, daily model retraining and publication run automatically in a production deployment on a VPS. The platform is ready to expand through additional city connectors.
09 — My role
Designed, engineered and operated independently from data ingestion to production deployment.
I independently designed and developed the complete platform: the architecture, PostgreSQL schema, city-specific data ingestion, validation, duplicate detection, historical database and data-enrichment workflow.
I also built the prediction engine, Flask application, Leaflet and OpenStreetMap frontend, deployment workflow, CI/CD pipeline and production operations on the VPS.
10 — Lessons learned
Historical data creates value
Live data is useful. Historical data enables intelligence: behaviour, trends, occupancy evolution and forecasts become possible only after observations accumulate.
Build reusable pipelines
Separating data collection from presentation makes expansion straightforward. A new source does not require a new application.
Design for future analytics
Capturing contextual information from day one creates a foundation for forecasting and future machine learning capabilities.