Roles and access
- admin: full access, manages geofence configurations, sees all hubs.
- logist: creates/edits routes within allowed hubs, submits for approval.
- security: view/approval, can leave a route proposal.
- user: read‑only.
- Access to data is filtered by “hub” (one or a list).
Key features
- Map:
- Display of vector geofences (layers/tilesets) filtered by hubs.
- Toggle “Show/Hide geofences”, labels (centroids) and popup with field passport.
- Ukrainian language labels for base layers.
- Search for populated areas, map style switch.
- Fine “road grid” as a separate layer.
- Route:
- Click-on-map adds points; route is plotted on roads; segmentation into parts.
- Two “rulers” (start/finish) for manual segments, their distance is added to the total.
- Editing: insert after, delete point, clear route/rulers.
- Real-time km calculation.
- Import/export JSON and KML.
- Route database:
- Save/update, prevent duplicates.
- Search: prefix + “contains” (n-grams), pagination/loading.
- Display selected route on the map, preview.
- Approval:
- Statuses draft/pending/approved/rejected, comment, revisions.
- Route proposal from security service (separate overlay), accept/reject.
- Notifications in the interface (local), optionally external notification channel.
- Admin utilities:
- Tilesets configuration editor (key, url, source-layer, hubs, enabled).
- GeoJSON-Builder: drawing/editing polygons, export; view tilesets as on the main.
Data and models (summary)
- DB (document-oriented or SQL with similar entities):
- routes: { name, fromCode, toCode, fromLabel, toLabel, fromName, toName, routeType, purpose, hub, points[], startRuler[], endRuler[], distance_km, routeKey, approval{}, proposal{}, updatedAt, createdBy…; index fields: nameLower, fromLabelLower, toLabelLower, fromNameLower, toNameLower, …Ngrams, searchNgrams }.
- users: { role, allowedHubs[] | all }.
- config/tilesets: array of elements { key, url, layer, hubs[], enabled }.
- logists: { id, name, active, sort }.
- route_logs: { routeId, type, ts, actor, summary }.
- routeKeys (optional): { routeId, … } for unique route codes.
- Object storage (optional): geozones/all.geojson (as an alternative to tilesets).
Integrations (the performer chooses providers)
- Map: vector tiles, styles, geocoding, route building on roads.
- Identification: email/password or another standard provider.
- Database: documents/tables with indexing and prefix search capabilities.
- Static hosting and CDN.
- Lightweight backend/API or serverless functions for:
- saving a route with token verification,
- sending external notifications (e.g., to messenger).
- Object storage (if GeoJSON files are needed).
Non-functional requirements
- Access control by roles and hubs (read/write/delete).
- Cache/offline resilience for directories and lists (if possible).
- Security: protection against XSS, secure headers, rate-limit on API, token ID verification.
- Performance: map smooth on desktop and mobile, lazy requests, debounce.
- Logging of route changes (short and detailed summary of changes).
UI/screens
- Main with map: creation panel, database panel, approval panel, docks at top/bottom.
- Admin: tilesets editor.
- Admin: GeoJSON-Builder.
- Export/Import.
- Route review page via link.
Search and indexes (summary)
- Prefix indexes: nameLower, fromLabelLower, toLabelLower.
- Additionally n-grams (nameNgrams, fromNgrams, toNgrams, searchNgrams) for contains.
- Filter by hub in queries.
- Necessary indexes for the chosen DB need to be described.
Security (summary)
- No secrets in client code/repository.
- Map token — public, but domain-restricted.
- Database access rules: read/write by roles and allowedHubs.
- API: token ID verification, CORS, Helmet/headers, limits.
- CSP/Referrer-Policy/HSTS in production.
Deliverables
- Ready web application (static files + minimal API/functions).
- Documentation:
- Data schemas and list of indexes.
- Deployment instructions (local/prod).
- Description of configs (env), tokens, and limits.
- Set of test data (several routes, tilesets config).
- Short video or screencast flow: create → save → search → approve.
Acceptance criteria
- A user with the role of logist creates a route, saves it, submits for approval; sees only their hubs.
- admin changes tilesets config, immediately sees updated layers on the map and in Builder.
- Search works (prefix + contains), viewing and previewing the route.
- Proposal from security is displayed and can be accepted/rejected.
- Geofences are hidden by default; labels and popups work under the hub filter.
What the performer should define/propose
- Specific providers: maps (vector tiles/routes/geocoding), authentication, DB, static hosting, serverless/API, object storage, notification channel.
- Infrastructure plan and budget (free/paid limits).
- Deployment/CI scheme and monitoring.
- Authorization details (sessions, key rotation, password policy).
Additionally (optional)
- Extended security audit.
- Data migration GeoJSON → tilesets.
- Reservation of unique route codes through transactions/queues.
- Theming UI, localizations.
