What does the system do?

It allocates and releases parking slots in real time against a normalized SQL backend, and exposes both live occupancy and historical analytics through a Streamlit dashboard.

Why a SQL backend rather than in-memory state?

Persisted state survives restarts and makes historical occupancy analysis possible, which an in-memory allocator cannot provide.

How is double allocation prevented?

Slot assignment and release run as database transactions, so concurrent entries cannot claim the same slot.

Was the work published?

Yes, it was published in IJCRT in September 2025 with Nithin K as lead author.

What are the system's limits?

It models a single operator-controlled lot. Supporting many independent hosts required the rebuild that became LumoroX Park.

Where can I read the code?

The repository is at github.com/Nithin69-k/Parking-Space-Management-System.

Lead Author · Full-stack · 2025

Parking Space Management System

Published real-time slot allocation research — the foundation of LumoroX Park.

PythonSQLStreamlitAnalytics

View code Evolved into: LumoroX Park

Parking Space Management System — Published real-time slot allocation research — the foundation of LumoroX Park.

Goals

Cut the capacity wasted by manual allocation and poor slot visibility.
Keep live slot state accurate and persisted, not held in memory.
Give operators historical occupancy analytics, not just a live view.
Document the approach to a publishable standard.

Approach & architecture

1
Normalized schema
A SQL backend modelled lots, slots, vehicles and sessions so state survives restarts and supports history queries.
2
Allocation logic
Slots are assigned and released transactionally, preventing double allocation under concurrent entries.
3
Streamlit dashboard
A live operator view of occupancy plus historical charts over the session table.
4
Write-up
Method and results were written up and peer-reviewed for publication.