OpenBarriers — Kraków bez barier

Prototyp na hackathon HackYeah 2026 (wyzwanie „Kraków bez barier”). OpenBarriers to mapa z kartami dostępności i API, które nigdy nie mówią „dostępne / niedostępne” – zamiast tego ocenia każdą cechę miejsca osobno względem profilu potrzeb użytkownika, a przy każdej informacji pokazuje źródło, datę potwierdzenia i status wiarygodności.

Grupa docelna: osoby poruszające się na wózkach (aktywnych i elektrycznych) oraz rodzice z wózkami dziecięcymi. Aplikacja nigdy nie pyta o niepełnosprawność – wyłącznie o bariery i udogodnienia.

Demo: https://demo.openbarriers.divadsn.me

Zasady nadrzędne

1. Nigdy „dostępne / niedostępne”. Każda cecha miejsca jest oceniana osobno względem profilu: pasuje / częściowo / nie pasuje / brak danych.
2. Brak danych ≠ dostępne. Brakująca informacja jest zawsze prezentowana jako brak danych, nigdy jako pozytywna.
3. Każda informacja ma metadane: source (MSIP / Otwarte Dane / OSM / właściciel obiektu / społeczność), confirmed_at (data potwierdzenia) i trust (verified / unverified / conflicting / missing). Metadane są widoczne dla użytkownika.
4. Dane przykładowe są jawnie oznaczone (is_sample: true) i wyświetlane z banerem, którego nie da się ukryć.
5. Niedostępność źródła nie zatrzymuje aplikacji – serwujemy ostatnie dane z cache z widoczną datą i komunikatem.

Struktura monorepo

Katalog	Zawartość
backend/	FastAPI + PostgreSQL/PostGIS + Redis – API miejsc, tras, zgłoszeń, panel operatora oraz agregator danych (OpenStreetMap, MSIP, Otwarte Dane)
frontend/	React 18 + TypeScript + Vite + MapLibre GL – mapa, karta dostępności, profil potrzeb, trasy, widget <open-barriers-card> do osadzania
docker/	Produkcyjny stack wdrożenia (nginx proxy + docker compose + skrypty setup/deploy) dla demo.openbarriers.divadsn.me

Szczegóły: backend/README.md · frontend/README.md · docker/README.md · dostępność cyfrowa: frontend/ACCESSIBILITY.md

Monorepo powstał z połączenia trzech repozytoriów (backend, frontend, docker) z pełnym zachowaniem historii git (subtree merge).

Uruchomienie — jedna komenda

docker compose up --build -d                    # db (PostGIS 16), redis 7, backend, agregator, frontend
docker compose exec backend python -m app.seed  # miasta + dane przykładowe (idempotentnie)

• Aplikacja: http://localhost:5173
• API: http://localhost:8000 · dokumentacja (Swagger): http://localhost:8000/docs
• Panel demo (wymuszenie scenariuszy „sprzeczne dane” / „brak danych” / „źródło niedostępne”): http://localhost:5173/?dev=1
• Widget: http://localhost:5173/widget/open-barriers-card.js (fallback iframe: /widget/embed.html?place-id=krk-0002)

Dane przykładowe. Nazwy i położenie miejsc są prawdziwe, ale wartości dostępności są fikcyjne (is_sample: true). Aplikacja pokazuje stały baner „Dane przykładowe – prototyp”.

Lokalnie bez Dockera

# backend (Python 3.12, uv)
cd backend && uv sync && uv run uvicorn app.main:app --reload    # http://localhost:8000

# frontend (Node 22+, pnpm przez corepack)
cd frontend/frontend && pnpm install && pnpm dev                  # http://localhost:5173

Frontend bez VITE_API_URL działa na wbudowanym mocku API. Z prawdziwym backendem: VITE_API_URL=http://localhost:8000 pnpm dev.

Testy i linter:

cd backend && uv run pytest && uv run ruff check . && uv run mypy app
cd frontend/frontend && pnpm lint && pnpm typecheck && pnpm test   # vitest + axe-core (WCAG)

Scenariusz demo (~3 min)

1. Profil potrzeb – preset „Wózek aktywny” (0 stopni, drzwi od 80 cm, bez kostki), w pełni edytowalny; zapis tylko lokalnie w przeglądarce.
2. Mapa i lista – Stare Miasto; pinezki różnią się kształtem i ikoną (✓ / ◐ / ✗ / ?), lista obok to pełna tekstowa alternatywa mapy.
3. Karta miejsca – każda cecha w jednym wierszu: wartość → źródło → data → wiarygodność → dopasowanie do profilu; sekcja „Dlaczego ten wynik?”.
4. Dane sprzeczne – np. OSM: 0 stopni vs zgłoszenie społeczności: 2 stopnie; obie wartości obok siebie, prośba o potwierdzenie, operator rozstrzyga w panelu.
5. Brak danych – „Nie potwierdzamy dostępności tego miejsca” + przycisk „Dodaj informacje”.
6. Zgłoszenie – 3 kroki, anonimowo; od razu widoczne na karcie jako „niezweryfikowane”.
7. Źródło niedostępne – baner z datą danych z cache, aplikacja działa dalej.
8. Trasa A→B – „najkrótsza” vs „najmniej barier”, przekrój nawierzchni, ostrzeżenia, pełna lista etapów.
9. Widget – generator kodu <open-barriers-card> dla hoteli i organizatorów wydarzeń.

Kontrakt API (wybrane endpointy)

Endpoint	Opis
GET /places?bbox=&profile=	GeoJSON FeatureCollection; każda cecha ma value, source, confirmed_at, trust, match
GET /places/{id}	Pełna karta miejsca: konflikty i historia potwierdzeń
GET /route?from=&to=&profile=&variant=	Trasa z segmentami i ostrzeżeniami (prototyp: trasy fixture)
POST /reports	Zgłoszenie błędu / nowej wartości cechy (anonimowe, ze zdjęciem opcjonalnie)
POST /places/{id}/confirm	Potwierdzenie aktualności danych miejsca
GET /sources/status	Dostępność każdego źródła danych
GET /cities	Lista obsługiwanych miast

Każda odpowiedź zawiera is_sample oraz nagłówek X-Sources-Status. Pełny schemat: backend/openapi.json lub /docs na działającym API.

Źródła danych

Źródło	Status	Uwagi
OpenStreetMap (Overpass API)	aktywne	tagi step_count, ramp:wheelchair, door:width, toilets:wheelchair; trust: unverified
MSIP (Kraków)	zgłaszany jako niedostępny	endpoint publicznego API zwraca HTML (2026-10-04)
Portal Otwarte Dane	zgłaszany jako niedostępny	brak CKAN /api/3 (2026-10-04)
Właściciel obiektu	przez panel #/osadz	status unverified
Społeczność	zgłoszenia w aplikacji	po moderacji operatora → verified

Konflikty między źródłami nie są ukrywane: karta pokazuje wszystkie sprzeczne wartości, a operator rozstrzyga je w panelu (/admin/conflicts).

Licencja

• Kod projektu: GNU GPL-3.0 — szczegóły w LICENSE.
• Dane OpenStreetMap: © OpenStreetMap contributors, licencja ODbL. Atrybucja jest wyświetlana na mapie w aplikacji.