CityPulse Lahore

Inspiration

Lahore regularly faces severe air-quality challenges, but most air-quality systems are reactive: they tell people what pollution is happening now or what happened earlier. For the Smart City Hackathon Lahore challenge “Predicting Problems Before They Happen, Not After,” we wanted to build something more proactive. That idea became CityPulse Lahore — an AI-powered urban intelligence platform designed around one question:

What is likely to happen next, where is the risk, and what should citizens do? Our core workflow is: Monitoring → Prediction → Risk Intelligence → Action

What it does

CityPulse Lahore predicts PM2.5 concentration one hour ahead and converts that prediction into understandable risk intelligence and citizen guidance. The platform currently supports 8 Lahore OpenAQ monitoring locations. Users can:

• Select a supported Lahore monitoring station
• View the latest available measured PM2.5
• View the predicted PM2.5 for the next hour
• See temperature and humidity conditions
• View the forecast risk level and response stage
• Receive citizen recommendations
• Explore supported stations on an interactive Lahore map
• Click an arbitrary point on the map and automatically use the nearest supported monitoring station The selected location is shared across the whole application, so the Command Centre, Forecast Intelligence, Risk Alerts, Data & Model view, and Lahore map all update together. CityPulse also clearly distinguishes between measured data, predicted data, and forecast risk intelligence. The risk classification is decision-support information and is not presented as an official regulatory AQI reading.

How we built it

We built CityPulse using real and open environmental data. For air quality, we used OpenAQ PM2.5 observations from Lahore monitoring stations. For weather, we used Open-Meteo hourly data including:

• Temperature
• Relative humidity
• Precipitation
• Wind speed
• Wind direction
• Surface pressure We first inspected and validated the datasets for timestamps, missing values, duplicates, station coverage, pollutant availability, date ranges, and outliers. Air-quality and weather observations were aligned by station location and UTC timestamp. The final multi-location machine-learning dataset contains:
• 54,727 complete ML samples
• 8 Lahore monitoring stations
• 31 features
• 1-hour prediction horizon For feature engineering, we used:
• Hour, day of week, month, and weekend indicators
• PM2.5 lag features at 1, 2, 3, 6, 12, and 24 hours
• PM2.5 rolling averages over 3, 6, 12, and 24 hours
• Weather variables
• Station identity and geographic features Lag and rolling features were calculated independently for each station so observations from different locations were never mixed. Because this is time-series data, we used a chronological 70% training, 15% validation, and 15% testing split instead of random shuffling. We compared:
• Linear Regression
• Random Forest Regressor
• Gradient Boosting Regressor
• XGBoost Random Forest provided the strongest balance of predictive performance, stability, simplicity, and deployment suitability. The final deployment model is a compact station-aware Random Forest Regressor. Its held-out test performance is:
• MAE: 6.9526 µg/m³
• RMSE: 11.4059 µg/m³
• R²: 0.7872 The original multi-location Random Forest was approximately 620 MB. We optimized it into a compact 4.07 MB deployment model while maintaining very similar predictive performance. The backend was built with FastAPI, while the frontend uses React, TypeScript, Vite, Tailwind CSS, Recharts, React Leaflet, and OpenStreetMap.

Challenges we ran into

One of the biggest challenges was working with real environmental data. Different monitoring stations had different amounts of missing data and different levels of timestamp coverage, so careful validation was necessary before training any model. Another challenge was preventing time-series data leakage. We had to make sure that future PM2.5 observations were never used to predict earlier timestamps. Expanding from a single-station prototype to a reliable multi-location model was another major challenge. PM2.5 lag and rolling features had to be calculated independently for every station. We also had a deployment challenge when the full Random Forest model reached approximately 620 MB. We solved this by training and validating a compact deployment version that reduced the model size to only 4.07 MB. On the frontend, we needed location selection to affect the entire application rather than only the map. We solved this using shared React state and station-specific API requests.

Accomplishments that we're proud of

We are proud that CityPulse is not just a visual dashboard or mockup. It contains a complete working pipeline: Real Data → Validation → Feature Engineering → Machine Learning → FastAPI → Interactive Dashboard → Risk Intelligence We successfully built:

• A real multi-location Lahore air-quality dataset
• Leakage-safe time-series feature engineering
• Chronological model evaluation
• A station-aware PM2.5 forecasting model
• A compact cloud-deployable ML model
• A FastAPI prediction backend
• A polished Smart City Command Centre
• An interactive map with 8 supported Lahore monitoring locations
• Nearest-supported-station selection
• Forecast-based risk classification
• Citizen recommendations
• Automated multi-location system validation Our final automated QA confirms that all 8 location dashboards, location-specific predictions, model metrics, API health checks, and nearest-station lookup are functioning correctly.

What we learned

The biggest lesson was that building a credible AI smart-city product is not only about choosing a machine-learning algorithm. A reliable predictive system also requires:

• Careful data validation
• Correct timestamp alignment
• Proper handling of missing data
• Leakage-free feature engineering
• Chronological evaluation
• Honest geographic coverage
• Clear separation of measured and predicted information
• Useful communication of model output to citizens We also learned that deployment engineering matters. A slightly more compact model that can be deployed reliably can be more valuable than a very large model with only a tiny performance improvement.

What's next for CityPulse Lahore

The current version focuses on solving the core one-hour PM2.5 forecasting problem reliably. Future versions could include:

• Automated near-real-time OpenAQ data ingestion
• Scheduled hourly prediction updates
• More Lahore monitoring stations
• Multi-hour PM2.5 forecasting
• Prediction uncertainty intervals
• Traffic and mobility data
• Weather forecast features
• Automated pollution-risk notifications
• Historical urban intelligence reports
• Spatial interpolation when sufficient sensor density is available Our long-term vision is to expand CityPulse into a reusable predictive urban intelligence layer that helps cities move from simply monitoring problems to anticipating them. > Monitoring → Prediction → Risk Intelligence → Action

Built With

• air-quality
• artificial-intelligence
• data-visualization
• fastapi
• lucide
• machine-learning
• numpy
• open-meteo
• openaq
• openstreetmap
• pandas
• pm2.5
• python
• random-forest
• react-leaflet
• recharts
• rest-api
• scikit-learn
• smart-city
• tailwind-css
• time-series-forcasting
• typescript
• vite
• xgboost