RIDE360 | Urban Mobility Analytics & Intelligence Platform

An end-to-end Analytics Engineering and Business Intelligence portfolio project that transforms raw ride-booking records into a structured PostgreSQL data warehouse, reusable SQL analytics, interactive Streamlit and Power BI reporting, and a containerized analytics application.

Python • PostgreSQL 16 • Advanced SQL • Pandas • Power BI • DAX • Streamlit • Plotly • Docker • GitHub Actions

RIDE360 explores the operational performance of an urban ride-booking platform using 150,000 booking records.

The project addresses five business questions:

1. How effectively does booking demand convert into completed rides?
2. Where are cancellations and service failures concentrated?
3. When does demand peak, and what does that imply for capacity planning?
4. How do vehicle categories and locations differ in performance?
5. Which operational improvements should be prioritized?

The solution combines reproducible data pipelines, analytical SQL, data-quality controls, interactive visualizations, executive BI reporting, and deployment engineering.

Project deliverables: PostgreSQL analytics warehouse · Streamlit analytics portal · six-page Power BI executive report (user-reported complete) · CEO strategic business report · Docker application · automated CI.

Portfolio scope: RIDE360 is an analytics portfolio project using a historical booking dataset. It is not presented as a live operating company, and its recommendations have not been experimentally validated.

Important: Completed booking value is a dataset-reported monetary measure, not verified recognized revenue. Currency and financial recognition rules have not been independently established.

• Driver cancellations are the largest cancellation category, representing 27,000 booking records.
• 18:00 is the peak booking hour, with 12,397 bookings.
• July records the highest monthly demand, with 12,897 bookings.
• Auto is the most frequent vehicle category, with 37,419 bookings.
• Khandsa is the highest-volume pickup location, with 949 bookings.

These findings identify opportunities for cancellation analysis, capacity planning, and location-level operational monitoring. They do not, by themselves, establish causation.

Historical ride-booking dataset (150,000 records)
                   |
                   v
Python validation + idempotent ingestion + batch reconciliation
                   |
                   v
PostgreSQL 16 warehouse
   |-- ride360_raw       (lossless source records)
   |-- ride360_staging   (standardized records)
   |-- ride360_analytics (SQL business views and marts)
   |-- ride360_audit     (batch and quality checks)
                   |
                   v
Business metrics + demand / cancellation / vehicle / location views
                   |
          +--------+------------------+
          |                           |
          v                           v
16 materialized cache views     Power BI Desktop
          |                     executive intelligence
          v                           |
Streamlit + Plotly portal       Six-page business report
          |
Dockerized local application
          |
GitHub Actions: lint, selected tests and Docker build

Architecture note: Power BI connects to PostgreSQL analytical views; the 16 cached materialized views primarily support the Streamlit analytics access layer. Docker and CI are engineering components, not proof of public hosting.

The Streamlit application provides seven analytical sections:

The Streamlit interface can be launched locally. Add verified Streamlit screenshots here when committed to the repository.

The Power BI report complements the Streamlit analytics portal with an executive-facing narrative and an interactive business improvement scenario. Its six pages were completed according to the project owner's latest update; the actual .pbix and exported screenshots have not been independently audited here.

BI techniques: PostgreSQL import, Power Query type validation, DAX measures, KPI cards, time-series visualizations, matrices with conditional formatting, page navigation and what-if scenario analysis. Aggregated SQL views are handled at their respective grains rather than being indiscriminately joined.

• Completion: 93,000 of 150,000 booking records completed (62.0%).
• Cancellations: 37,500 bookings cancelled (25.0%); 27,000 were driver cancellations (72.0% of cancellations).
• Peak hour: 18:00, with 12,397 booking records.
• Peak month: July 2024, with 12,897 booking records.
• Leading vehicle category: Auto, with 37,419 bookings.
• Leading pickup location: Khandsa, with 949 bookings.
• Completed booking value: 47,260,574 in dataset units; currency and revenue recognition are unverified.

Expected local report structure (add actual exported files to GitHub before linking them as downloadable assets):

reports/powerbi/
|-- RIDE360_Intelligence.pbix          # Editable report; typically attached to a GitHub Release
|-- RIDE360_Theme.json                # Executive dark theme
|-- RIDE360_Executive_Report.pdf      # Exported six-page BI report
|-- screenshots/
|   |-- 01_executive_overview.png
|   |-- 02_cancellation_intelligence.png
|   |-- 03_demand_capacity.png
|   |-- 04_vehicle_performance.png
|   |-- 05_location_intelligence.png
|   `-- 06_strategy_recommendations.png

Preview: Once the screenshots are committed, add the Executive Overview image at the top of this README and link the remaining five pages. The .pbix is excluded by the existing Git ignore rules; publish it as a reviewed GitHub Release asset if distribution is appropriate. Power BI Import files may contain embedded data and connection information.

The PostgreSQL warehouse organizes data into four logical schemas:

• ride360_raw — lossless source ingestion
• ride360_staging — cleaned and standardized records
• ride360_analytics — analytical views and business marts
• ride360_audit — data-quality checks and audit outputs

Booking IDs are not guaranteed to be unique in the source data.

The dataset contains:

• 148,767 distinct booking IDs
• 1,224 repeated-ID groups
• 2,457 rows belonging to repeated-ID groups

RIDE360 preserves these source records and uses a surrogate identifier in the raw warehouse layer rather than incorrectly treating the booking ID as a unique primary key.

The project includes:

• Schema and business-rule validation
• Warehouse quality checks
• Analytical consistency checks
• Automated Python tests
• Materialized-view source-to-cache comparisons

16 of 16 materialized analytics views passed source-to-cache verification.

The dashboard supports cached analytical queries through PostgreSQL materialized views.

Performance measurements from the local benchmark include:

These are local benchmark observations, not guaranteed production performance.

• Python 3.11+
• Docker Desktop
• PostgreSQL 16 or a compatible PostgreSQL instance
• PowerShell or a compatible terminal

git clone https://github.com/sharmaditya0010RS/Ride360-URBAN-MOBILITY-INTELLIGENCE-PLATFORM.git
cd Ride360-URBAN-MOBILITY-INTELLIGENCE-PLATFORM

python -m venv .venv

On Windows PowerShell:

.\.venv\Scripts\Activate.ps1

Install the project and dashboard dependencies:

python -m pip install -e .
python -m pip install -r requirements-dashboard.txt
python -m pip install pytest ruff

Create a local .env file with the database settings appropriate for your PostgreSQL instance.

DB_HOST=127.0.0.1
DB_PORT=5433
DB_NAME=ride360
DB_USER=your_database_user
DB_PASSWORD=your_database_password

Never commit credentials or .env files.

The dashboard requires an initialized RIDE360 warehouse with the corresponding analytical views or materialized views. The raw source dataset is not distributed in this repository.

$env:RIDE360_USE_CACHE = "1"
python -m streamlit run dashboard/app.py

Open:

http://localhost:8501

A Dockerfile and Docker Compose configuration are included.

The Compose setup expects a local .env.dashboard containing database credentials and an accessible PostgreSQL warehouse.

docker compose build dashboard
docker compose up -d dashboard
docker compose ps

Open:

http://localhost:8501

See docs/deployment.md for deployment-specific details.

Note: This is a local Docker deployment workflow, not a publicly hosted dashboard.

Run static checks:

python -m ruff check .

Run the selected database-independent unit test suite:

python -m pytest -q \
  tests/test_business_rules.py \
  tests/test_cli.py \
  tests/test_dashboard_data.py \
  tests/test_event_rules.py \
  tests/test_metadata.py \
  tests/test_phase1.py \
  tests/test_profiling.py \
  tests/test_quality.py \
  tests/test_report_catalog.py

The selected suite passed 85 tests in local verification.

GitHub Actions currently runs:

• Lint and selected unit tests
• Docker image build

Database-dependent integration tests require a configured warehouse and are not part of the current GitHub Actions checks.

RIDE360/
|
|-- .github/workflows/      # CI pipeline
|-- dashboard/              # Streamlit application
|   |-- assets/             # Dashboard styling
|   |-- pages/              # Analytical dashboard pages
|
|-- data/                   # Local data directories
|-- docs/                   # Engineering and deployment docs
|-- reports/                # Reports and project inventory
|   |-- powerbi/           # Power BI theme, report exports and screenshots
|-- scripts/                # Benchmarking and verification
|-- sql/                    # Warehouse and analytical SQL
|-- src/ride360/            # Python application package
|-- tests/                  # Automated tests
|
|-- Dockerfile
|-- compose.yaml
|-- pyproject.toml
|-- requirements-dashboard.txt
|-- README.md

Holding historical booking volume fixed at 150,000:

The target is a 5-percentage-point absolute reduction, or a 20% relative reduction in cancellations. This is a planning calculation only: no pilot, causal impact, incremental completed rides, revenue uplift or cost savings have been demonstrated.

A separate 15-page CEO strategic business and technical report has been prepared, covering the operating funnel, customer and location intelligence, opportunities, warehouse architecture, testing, deployment and a proposed operational roadmap. Add its final PDF to reports/ and link it here once committed to the repository. This document is a portfolio briefing, not an audited financial report.

• Data profiling and source-quality analysis
• PostgreSQL analytical warehouse
• SQL analytics and business intelligence
• Interactive Streamlit dashboard
• Materialized analytics cache
• Docker deployment configuration
• GitHub Actions CI
• Power BI executive reporting (completed as reported; final file review pending)
• Business-impact case study and CEO strategic briefing (scenario-based)
• Expanded database integration testing in CI
• Verify and publish final Power BI PDF, screenshots and GitHub Release asset

1. Confirm the .pbix opens and all six pages show correct values.
2. Export the Power BI PDF and six real screenshots into reports/powerbi/.
3. Verify no sensitive information is included in shared report files.
4. Commit the theme, PDF and screenshots; attach the .pbix to a GitHub Release if appropriate.
5. Add verified asset links and a real executive dashboard screenshot to this README.
6. Publish the 15-page CEO PDF in the repository only after confirming the final report version.

RIDE360 emphasizes:

• Data integrity: Preserve source records and explicitly handle duplicate business identifiers.
• Reproducibility: Keep transformations, tests, and deployment configuration in version control.
• Performance: Separate analytical consumption from expensive source-view computation.
• Security: Use read-only database access for dashboard queries.
• Business clarity: Distinguish observed metrics from estimates, assumptions, and scenarios.

Aditya Sharma

RIDE360 — Turning urban mobility data into operational intelligence.