PARADA documentation.

Overview

PARADA helps drivers find available parking and helps administrators monitor small-to-medium parking facilities (roughly 50–100 spaces across several zones). Instead of a sensor on every slot, it counts vehicles at zone gates with standard cameras and OCR, and keeps occupancy per zone.

The authoritative figure is zone availability: available = capacity − occupied. Parking slots exist for layout and inventory only and are never derived from camera occupancy.

Source: README.md, docs/database/model.md

Repository layout

Source: README.md

How data flows

Camera → Vision/OCR → API → Domain → Database
Mobile → API → Domain → Database
Admin  → Next.js proxy → API → Domain → Database
Realtime (SSE) → Admin + Mobile

The backend is the only authority on parking state. Vision only identifies what it sees and posts it over HTTP; it never touches the database. Neither client reaches the database directly; the admin app goes through a server-side proxy that keeps the session token in an HttpOnly cookie. Realtime updates are Server-Sent Events, published only after their transaction commits.

Source: README.md, docs/architecture/roadmap.md

Getting started

• Node.js 18+ and npm 9+.
• Python 3.11, only for the vision/OCR service.
• No PostgreSQL install and no Docker: the database package runs an embedded PostgreSQL 18 on port 5442.

npm install
# copy each package's .env.example to .env and fill in real values; never commit secrets
PARADA_SEED_ADMIN_PASSWORD=<strong-admin-password>
PARADA_SEED_USER_PASSWORD=<strong-user-password>
npm run setup -w @parada/vision   # vision virtualenv (optional)

The seed refuses to run without those two passwords outside the test environment.

Source: README.md, docs/how-to/setup.md, docs/how-to/run-and-test-locally.md

Running it

npm run dev         # database + API + admin + mobile
npm run dev:api     # API only
npm run dev:admin   # admin only
npm run dev:mobile  # mobile only (Expo LAN mode)
npm run db:start    # start the embedded database   (db:stop to stop it)
npm run dev -w @parada/vision      # vision service (FastAPI) — not started by npm run dev
npm run camera -w @parada/vision   # camera runtime: USB / RTSP / video file

On a phone, point EXPO_PUBLIC_API_URL at your machine’s LAN address, not localhost.

Source: README.md

Testing

npm run db:start
npm run db:test:setup -w @parada/database   # creates parada_test + parada_test_api
npm run test

API and database suites run against real PostgreSQL and refuse to start unless pointed at a test database. Measured in Phase 14: types 9, database 49, API 267, admin 79, mobile 324 tests passing; vision 73 passing with 2 opt-in live tests skipped.

These are unit and integration results. No on-device or deployment testing is claimed. The OCR evaluation is a characterisation on a synthetic dataset (1,250 generated images), not a production accuracy claim.

Source: README.md, docs/vision/phase14-evaluation.md

Adding a zone

1. Sign in to the admin dashboard and open Zones.
2. Choose New zone and fill in name, code (what drivers see at the gate), an optional description, capacity (the authoritative availability number), and optional navigation latitude/longitude. Directions stay off in the app until both are set.
3. Submit. This calls POST /admin/zones and creates the zone as active. Zones are deactivated, never deleted, so their history is kept.

Source: docs/how-to/add-a-zone.md

Adding a camera

Two parts, both required:

1. Register the logical camera in the admin dashboard (Cameras → Register camera): a permanent identifier such as CAM-A01, its zone, its gate direction (entry, exit or bidirectional) and status. Direction, zone and status are enforced by the backend on every event.
2. Point a frame source at it in the vision service: a USB camera, an RTSP stream or a video file. The service reads a capped number of frames per second (2 by default) and posts plate events to the API.

Source: docs/how-to/add-a-camera.md, docs/vision/architecture.md

API at a glance

Source: docs/api/README.md

Deployment

One application, three deployment profiles chosen by infrastructure and configuration alone:

• Local: database, API, admin and vision on the facility network; cameras over RTSP on the LAN.
• Online: API, admin and database on remote hosts behind HTTPS.
• Hybrid (recommended for the capstone): online API, admin and database, with vision on the facility network posting over HTTPS. Cameras and raw frames never leave the site.

Status: Phase 15 (Deployment) is pending. Every profile is deployable and its build, migration and start-up path is verified on Linux, but no production deployment has been made.

Source: docs/how-to/deploy.md, docs/architecture/roadmap.md

Roadmap

Phases 0–14 are complete: requirements and architecture, infrastructure, database, backend, authentication, vision integration, guest admission, reservations and assignment, the admin and mobile apps, real OCR, camera provisioning, realtime, full integration, and testing with the accuracy evaluation. Phase 15 (Deployment) and Phase 16 (Documentation and final review) are next.

Source: docs/architecture/roadmap.md