@golemio/public-transport 0.1.0

package/docs/processing/transferboards_filtering.md

@@ -0,0 +1,327 @@
+## v4/pid/transferboards filtering pipeline (newcomer guide)
+
+This section documents every filtering and transformation step executed by the `GET /v4/pid/transferboards` endpoint, in the order they actually run. The goal is to help a developer who is new to the codebase understand **what** each stage does, **why** it exists, and **where** the code lives.
+
+---
+
+### Overview
+
+The endpoint answers the question: _"Given that I am on vehicle X arriving at stop Y, which onward connections should I show on the transfer board?"_
+
+The answer is not simply "all departures from stop Y in the next hour" — many departures must be filtered out because they go back the way the passenger just came, or depart too soon to catch, or are irrelevant in-network transfers. The pipeline also specially handles **guaranteed transfers** (connections the operator has contractually promised to wait for).
+
+**Primary source files:**
+- `src/output-gateway/pid/controllers/v4/V4TransferBoardsController.ts` — orchestrates the full pipeline
+- `src/output-gateway/pid/service/facade/TransferFacade.ts` — fetches the cache, runs line-direction filters
+- `src/output-gateway/pid/helpers/TransferBoardFilter.ts` — static filter methods (time, name, deduplication)
+- `src/output-gateway/pid/helpers/TransferBoardSorter.ts` — sort pipeline
+- `src/output-gateway/pid/service/transformations/TransferDepartureCacheTransformation.ts` — output grouping/capping
+
+---
+
+### Stage 1 — Request validation and parameter parsing
+
+**Where:** `V4PIDRouter.ts` (validation middleware) + `V4TransferBoardsController.ts` (top of `getTransferBoards`)
+
+The endpoint accepts two mutually exclusive identification modes:
+
+- **ASW mode** — `aswId` + `vehicleRegistrationNumber` + `routeType`
+- **CIS mode** — `cisId` + `tripNumber` (returns HTTP 501; not yet implemented)
+
+If neither set of params is provided, or both are, validation rejects the request early. CIS mode always returns `501 Not Implemented`.
+
+---
+
+### Stage 2 — Stop resolution (ASW → GTFS stop IDs)
+
+**Where:** `TransferFacade.getTransferCache()` → `gtfsStopsCache:*`
+
+A single ASW node can map to multiple GTFS `stop_id` values (e.g. platforms A and B at the same tram stop). The facade:
+
+1. Looks up all GTFS `stop_id` values for the given `aswId` from `gtfsStopsCache:{aswId}`.
+2. Fetches the stop names for those `stop_id` values.
+3. Groups them into **same-name clusters** — stops that share a `stop_name` (e.g. both platforms of "Náměstí Míru") are treated as one logical transfer point.
+
+This grouping matters later: only departures from stops in the same cluster pass the same-stop-name filters.
+
+---
+
+### Stage 3 — Current vehicle lookup
+
+**Where:** `V4TransferBoardsController.ts` + `vpPublicStopTimeCache:*`
+
+The controller looks up the arriving vehicle's trip data using `service-{routeType}-{registrationNumber}` as the key into `vpPublicStopTimeCache`. For buses, a fallback to the trolleybus key is tried if the bus key is missing (registration numbers are shared between the two types).
+
+This gives the controller the vehicle's **current `trip_id`** (called `currentTripId` throughout the codebase), which is central to guaranteed transfer detection and direction filtering.
+
+If the vehicle is not found in the stop-time cache, the response is `404 Not Found`.
+
+---
+
+### Stage 4 — Arrival time detection
+
+**Where:** `V4TransferBoardsController.ts` → `gtfsDelayComputation:{tripId}`
+
+The controller reads the vehicle's current trip from `gtfsDelayComputation`, which contains a per-stop array with both planned and predicted (delayed) times. It finds the entry for the target stop and extracts:
+
+- `plannedTimeFrom` — the GTFS scheduled arrival time at this stop
+- `delayedTimeFrom` — the real-time predicted arrival time (may differ due to delays)
+
+The departure cache window in Stage 5 is anchored on `delayedTimeFrom`. `plannedTimeFrom` is retained for infotext queries and as a fallback if the query-supplied `timeFrom` is later than the predicted arrival.
+
+---
+
+### Stage 5 — Departure cache fetch
+
+**Where:** `TransferFacade.getTransferCache()` → `gtfsPublicDepartureCache:*`
+
+The facade fetches candidates from `gtfsPublicDepartureCache:{stopId}` (a Redis sorted set, scored by planned departure timestamp) for each GTFS `stop_id` in scope.
+
+**Time window:**
+```
+from  = delayedTimeFrom − 61 minutes
+to    = delayedTimeFrom + 30 minutes
+```
+
+The anchor is `delayedTimeFrom` — the vehicle's predicted arrival time after applying its current delay (negative delay = early arrival is preserved). The 61-minute lookback catches transfer lines whose scheduled departure is in the past but which may still arrive at the stop after the current vehicle due to their own delay of up to 60 minutes.
+
+**Fetch limit:** `max(120, min(180, limit × 15))` items per stop. With the typical `limit=8`, this yields 120 items — sufficient for stops with up to ~90 departures per hour. The wide over-fetch ensures enough candidates survive later filtering to fill the requested `limit`.
+
+---
+
+### Stage 6 — Self-removal and same-line opposite direction filter
+
+**Where:** `TransferFacade.isDifferentLine()`
+
+Two types of departures are removed here:
+
+1. **Same trip** — the current vehicle's own trip (`currentTripId`) is removed. It should never appear as a "transfer option" for itself.
+2. **Same line, opposite direction** — departures on the same `route_short_name` + `route_type` but with a different `direction_id` are removed. These represent the return journey on the same line, which the passenger just came from (typically the previous stop). This check only applies when `departure.direction_id` is known (non-null); departures with unknown direction are kept.
+
+---
+
+### Stage 7 — Pre-filter: bus/tram/trolleybus at wrong-name stops
+
+**Where:** `TransferFacade.getTransferCache()` (inline, before returning)
+
+Before the expensive line-direction filter runs, a cheap pre-filter drops departures that are:
+- Route type **bus, tram, or trolleybus** (metro/train/ferry/funicular pass through unconditionally)
+- From a stop whose `stop_name` differs from the current stop's name
+
+**Exception:** if the departure has a non-empty `connections[]` array (meaning it is a possible guaranteed transfer), it is kept regardless of stop name. This is because a guaranteed transfer bus might legitimately be at a different-named stop.
+
+This pre-filter is a performance optimization — it eliminates obviously irrelevant candidates before the costlier stages.
+
+---
+
+### Stage 8 — Sort + real-time vehicle position join
+
+**Where:** `V4TransferBoardsController.ts`
+
+Remaining candidates are sorted by `departure_datetime` ascending, then each is joined with live vehicle positions from `vpPublicCache` (if the trip has an active vehicle). This enriches each candidate with:
+
+- `predictedDepartureDate` / `predictedDepartureTimestamp` — the RT-adjusted departure time
+- `is_wheelchair_accessible` — resolved from the RT vehicle descriptor if available (see Stage 9)
+
+---
+
+### Stage 9 — Wheelchair accessibility resolution
+
+**Where:** `DepartureBoardMapper.determineWheelchairAccessibility()`
+
+For each candidate departure, accessibility is determined differently by mode:
+
+| Mode | Source |
+|---|---|
+| **Metro** | `wheelchair_boarding` from the GTFS stop (stop-level, static) |
+| **All other** | `real_wheelchair_accessible` from the RT vehicle descriptor (boolean), or if absent: GTFS static `wheelchair_accessible` (trip-level, `GtfsTripWheelchairAccessEnum`) |
+
+The fallback to GTFS static data is the fix introduced in v5.7.1 (item 3 above).
+
+---
+
+### Stage 10 — Guaranteed transfer detection
+
+**Where:** `V4TransferBoardsController.ts` (`havingConnectionFromTripId`)
+
+A departure is a **guaranteed transfer** (Czech: _zaručený přestup_) when:
+
+1. Its `connections[]` array contains an entry where `from_trip_id === currentTripId`, AND
+2. The current vehicle's predicted arrival time is within the wait window:
+   ```
+   vehicleArrivalMs < departurePlannedMs + max_wait_sec × 1000
+   ```
+
+Guaranteed transfers receive special treatment in all subsequent stages — they can bypass nearly every filter and are always shown if time constraints allow.
+
+The result is two sets: `guaranteedTripIds` and `guaranteedConnections`.
+
+---
+
+### Stage 11 — Minimal transfer time filter
+
+**Where:** `TransferBoardFilter.minimalTransferTime()`
+
+Departures whose predicted departure is too close to the vehicle's arrival are dropped — not enough time to board. The required reserve is **platform-aware**, resolved per departure in `minimalTransferTimeMs` from the current stop's `platform_code` and the departure's `platform_code`. The first matching rule wins:
+
+| Mode | Minimum gap |
+|---|---|
+| Train | 120 s always (ignores platform) |
+| Metro | 60 s always (ignores platform) |
+| Funicular | 120 s always (ignores platform) |
+| Everything else (bus, tram, trolleybus, ferry) | 60 s if the departure is on a different platform, 0 s if on the same platform |
+
+**Platform comparison (`platformDiffers`):** two platforms count as different when either code is null/empty, or when the codes are not strictly equal (`!a || !b || a !== b`). So a missing or empty platform on either side means the 60 s reserve applies — never downgraded to 0 s. Train, metro and funicular are unaffected: their rules are checked before the platform comparison, so they always keep their fixed reserve even with a missing platform. Ferry has no dedicated rule — it falls through to the platform-comparison bucket, so in practice it gets 60 s (ferry departures never share a platform code with the current stop).
+
+**Guaranteed transfers are exempt** — the connection is guaranteed, so time is irrelevant. Departures with no predicted departure timestamp are dropped unless guaranteed.
+
+The current stop's platform reaches this stage via `transferCacheDto.currentStop?.platform_code ?? null` in `V4TransferBoardsController`.
+
+---
+
+### Stage 12 — Same-stop-name filter (Stage 2)
+
+**Where:** `TransferBoardFilter.sameStopNameTransfer()`
+
+A second pass of the stop-name check, applied after guaranteed transfers are identified. Rules:
+
+- Bus/tram/trolleybus at a stop with a different name than the arrival stop → **dropped**
+- Metro/train/ferry/funicular → **kept** (they serve different physical locations by design)
+- Any trip in `guaranteedTripIds` → **kept** (guaranteed transfer exemption)
+- Any trip in `keepAlwaysTripIds` (see Stage 14) → **kept**
+
+This stage is separate from the Stage 7 pre-filter because at Stage 7 we did not yet know which trips were guaranteed.
+
+---
+
+### Stage 13 — Categorise trips for line-direction filter
+
+**Where:** `V4TransferBoardsController.ts`
+
+Before running the direction filter, the controller categorises remaining candidates:
+
+- **Always keep:** guaranteed transfers + "keep always" types (metro, train, ferry, funicular)
+- **Needs filtering:** everything else (bus, tram, trolleybus that are not guaranteed)
+
+Only the "needs filtering" set of trip IDs is passed to `findRelevantTripIdsFromLines`. This avoids running direction analysis on trips that will be kept unconditionally.
+
+---
+
+### Stage 14 — Guaranteed transfer time adjustment
+
+**Where:** `V4TransferBoardsController.ts`
+
+For guaranteed transfers, the displayed departure time is **replaced** with the arriving vehicle's own predicted arrival time. This is the time the bus/tram will actually wait until, so showing the vehicle's arrival time as the "departure" is more useful to passengers than the originally scheduled departure time.
+
+---
+
+### Stage 15 — Sort (pre-output)
+
+**Where:** `TransferBoardSorter.sort()`
+
+A four-criterion stable sort applied before the direction filter:
+
+1. **Metro first** — metro departures before all others
+2. **Metro name ascending** — within metro, sort by `route_short_name` (A before B before C)
+3. **Departure time ascending** — earlier departures first
+4. **`direction_id` ascending** — tiebreaker for trips with identical departure times
+
+---
+
+### Stage 16 — Line-direction filter (`findRelevantTripIdsFromLines`)
+
+**Where:** `TransferFacade.findRelevantTripIdsFromLines()`
+
+This is the most complex stage. It determines whether each candidate trip is going somewhere _new_ for the passenger, or whether it is effectively doubling back along the route the passenger just arrived on.
+
+For all candidate trip IDs (plus the current trip), the facade loads their stop sequences from `gtfsTripStopsCache:{tripId}` via a single `MGET` call. Each cache entry contains an ordered list of `[stop_id, stop_name]` tuples representing the full route of the trip.
+
+Before comparison, each stop sequence is normalized: the GTFS `stop_id` is reduced to its ASW node number (`U64Z6P` → `64`), and **consecutive stops sharing the same node AND the same stop name are condensed into a single route point**. This handles trips with a doubled terminus — e.g. short trips of line 58 end with two Čakovice platforms (`U64Z6P`, `U64Z2P`); without condensation the second Čakovice would look like an extra stop the longer Miškovice trip does not serve, and the shorter trip would wrongly pass the forward-subset check below. Stops sharing a node but differing in name (e.g. Vítězné náměstí / Dejvická, both node `321`) are NOT merged, and non-consecutive revisits of the same node (e.g. lines looping through Černý Most) remain distinct route points.
+
+It then applies two sequential sub-filters:
+
+#### Sub-filter A: Forward-subset check (`filterOutForwardSubgroupOfLine`)
+
+**Question:** Does this candidate trip's future stops form a strict subset of the current vehicle's future stops?
+
+If every stop the candidate will visit is also a future stop on the current vehicle's route, then there is no point transferring — the passenger will get there anyway without changing. Such trips are **dropped**.
+
+**Example:** Current vehicle is bus 207 going A→B→C→D. Candidate bus 150 goes B→C. Since B and C are both future stops of 207, transferring to 150 is redundant → dropped.
+
+#### Sub-filter B: Backtracking conflict check (`filterOutLinesWithBacktrackingConflict`)
+
+**Question:** Do this candidate trip's next N stops overlap with the current vehicle's previous N stops in a way that suggests it is heading back the same way?
+
+Configured by `countPreviousStopsToAllow` (default `0`). The value defines how many of the current vehicle's previous stops the candidate trip is allowed to share in its upcoming stops. If the candidate shares more than that number, it is **dropped** (it's going backwards). `0` means no overlap is permitted at all. The actual lookback count is capped at `currentStopIndex` — cannot look back more stops than exist before the current position.
+
+The strictness of the stop matching is controlled by `isOppositeDirectionFilterStopNameStrict` (default `true`): when true, both `stop_id` AND `stop_name` must match; when false, only `stop_id`.
+
+---
+
+### Stage 17 — Combine approved trip IDs
+
+**Where:** `TransferBoardFilter.keepAlwaysLinesAndTripIds()`
+
+The final set of approved trip IDs is the union of:
+- `guaranteedTripIds` (from Stage 10)
+- `keepAlwaysTripIds` (metro/train/ferry/funicular, from Stage 13)
+- Trips that passed the direction filter (from Stage 16)
+
+All other trips are discarded from the candidate list here.
+
+---
+
+### Stage 18 — Output grouping and per-route cap
+
+**Where:** `TransferDepartureCacheTransformation.transform()`
+
+Before the final limit is applied, departures are grouped by route and capped to prevent one line from dominating the board:
+
+| Mode | Grouping key | Cap |
+|---|---|---|
+| **Metro** | `route_short_name + route_type + direction_id` | 2 departure times merged into one `departure_timestamp.minutes[]` entry |
+| **Non-metro** | `route_short_name + route_type + direction_id` | 2 separate departure entries per group |
+
+Both modes use the same grouping key. The `route_type` component prevents collisions between lines that share a `route_short_name` across transport types. The `direction_id` is resolved with the following fallback chain: `departure.direction_id` (from the precomputed departure cache) → `position.detailed_info.direction_id` (from the live vehicle position) → in-memory cache (keyed by `route_short_name + trip_headsign`, populated by earlier entries in the same batch) → `0`.
+
+---
+
+### Stage 19 — Final filter: limit, time window, deduplication
+
+**Where:** `TransferBoardFilter.filterDepartures()`
+
+The last stage applies three rules:
+
+1. **Time window cut:** departures after `arrivalTime + 1 hour` are dropped.
+2. **Trip deduplication:** if two entries share the same `trip_id`, only the first (earliest) is kept.
+3. **Limit:** the result is truncated to the requested `limit` (query parameter, default typically 10).
+
+**Guaranteed transfers are exempt from the time window and limit** — they always appear regardless of how many other results there are, as long as they are still within the `max_wait_sec` window.
+
+---
+
+### Quick reference: which filter each vehicle type is subject to
+
+| Filter | Bus/Tram/Trolleybus | Metro/Train/Ferry/Funicular | Guaranteed transfer |
+|---|---|---|---|
+| Stage 6 same-line opposite direction | Yes (when `direction_id` known) | Yes (when `direction_id` known) | Yes |
+| Stage 7 pre-filter (wrong stop name) | Yes | No | No (exempt) |
+| Stage 11 min transfer time | 60 s if different platform, 0 s if same platform | Train 120 s; metro 60 s; funicular 120 s; ferry uses platform rule (60 s / 0 s) | **No** |
+| Stage 12 same-stop-name | Yes | No | **No** |
+| Stage 16 direction filter | Yes | **No** | **No** |
+| Stage 17 combine | All types pass via their category | — | — |
+| Stage 18 per-route cap (2 entries) | Yes | Yes (metro grouped differently) | Yes |
+| Stage 19 limit | Yes | Yes | **No** |
+
+---
+
+### Key Redis keys used
+
+| Key pattern | Purpose |
+|---|---|
+| `gtfsStopsCache:{aswId}` | ASW node → GTFS stop_id mapping |
+| `gtfsPublicDepartureCache:{stopId}` | Sorted set of precomputed departures (score = departure Unix timestamp) |
+| `gtfsTripStopsCache:{tripId}` | Pre-computed ordered list of stops per trip (`[stop_id, stop_name][]`), used by line-direction filter |
+| `gtfsDelayComputation:{tripId}` | Per-trip RT stop times, delay, shapes |
+| `vpPublicStopTimeCache:{vehicleKey}` | Per-vehicle stop time lookup (used to identify current trip) |
+| `vpPublicCache:*` | Geo-indexed real-time vehicle positions |

package/docs/processing/trip_matching.md

@@ -0,0 +1,30 @@
+# Mapování MPVNet spojů na GTFS (nevlakové spoje)
+
+Platí pro autobusy (mimo DPP) a přívozy přijaté přes HTTP MPVNet (`provider_source_type` 0/1). Vlaky mají vlastní logiku (`getFindGtfsTrainTripsQuery`). DPP tramvaje/trolejbusy/metro nechodí přes MPVNet vůbec (viz [http_mpvnet.md](./input_realtime_data/http_mpvnet.md)) a párují se jinou cestou (`workers/runs`), tady popsanou logikou neprochází.
+
+## Klíč párování
+
+MPVNet atribut `lin` (číslo linky dle CIS) a `spoj` (číslo spoje dle CIS) se z příchozí zprávy uloží jako `cis_line_id` / `cis_trip_number` na řádku `vehiclepositions_trips`. `getFindGtfsCommonTripsQuery` (`RawQueryProvider.ts`) je hledá přímo v `ropidgtfs_precomputed_trip_schedule` podle:
+
+- `route_licence_number = cis_line_id`
+- `trip_number = cis_trip_number`
+- `date` v okně `[včera, dnes]` vztaženo ke skutečnému `start_timestamp` spoje
+
+Žádné spojení na `ropidgtfs_trips`/`ropidgtfs_routes`/zastávky není potřeba - `ropidgtfs_precomputed_trip_schedule` už má všechny potřebné sloupce (route_id, route_type, route_short_name, block_id, direction_id, shape_id, min/max_stop_time) denormalizované.
+
+## Proč okno dvou dnů a ne jen "dnes"
+
+Spoj, jehož první zastávka odjíždí až po půlnoci (GTFS zápis `>=24:00:00`), má v `ropidgtfs_precomputed_trip_schedule.date` předchozí kalendářní den. Zpráva z MPVNet ale nese reálný čas (žádná `>24h` notace), takže samotné datum zprávy neodpovídá datu ve schedule tabulce.
+
+Zároveň může být stejné `trip_id` platné jak včera, tak dnes (pravidelně jezdící spoj), takže nejde jen zkusit "dnes, a když nic, tak včera" - u obou dnů může něco vyjít, ale jen jeden je ten skutečně právě jedoucí.
+
+Řešení: pro každé `trip_id` v okně `[včera, dnes]` se spočítá `start_timestamp` (předpočítaný přes `gtfs_timestamp()`, řeší `>24h` notaci i DST) a vybere se ten řádek daného `trip_id`, který je časově nejblíž reálně pozorovanému `start_timestamp` spoje (`DISTINCT ON (trip_id) ORDER BY trip_id, distance_seconds`). Různá `trip_id` se takto nesbalí - pokud po tomhle výběru zbydou dvě různá `trip_id`, jde o skutečnou nejednoznačnost (viz níže).
+
+## Nejednoznačný a chybějící výsledek
+
+- Víc než 1 výsledné `trip_id` -> `TripsRepository.findGTFSTripIdBasic` výsledek zahodí, spoj zůstane nenapárovaný a zaloguje se `warn` (včetně `run_number` spoje a kandidátů).
+- 0 výsledků -> buď dopravce/linka nemá v `ropidgtfs_run_numbers` vůbec `trip_number` přiřazený (celá linka), nebo číslo spoje z MPVNet neodpovídá číslu přiřazenému v `ropidgtfs_run_numbers` pro stejný fyzický spoj (nesoulad mezi MPVNet a `ropidgtfs_run_numbers`, u jednotlivých spojů/dopravců).
+
+## Známé problémy (aktuální stav)
+
+- **Linka 523 (Arriva SČ, Plzeň)** - `ropidgtfs_run_numbers` přiřazuje `trip_number` v jiné číselné řadě (např. 1008), než jaké `spoj` hlásí reálná MPVNet zpráva pro stejný fyzický spoj (např. 16) - nejde o mezeru, ale o neshodu dvou číslování. Nahlášeno poskytovateli dat, čeká se na vyjádření.

package/docs/processing/vehicle_types.md

@@ -0,0 +1,32 @@
+# Mapování MPVNet vehicle type na GTFS
+
+## Typ vozidel podle MPV
+- 0 - neznámý nebo vlak
+- 1 - metro
+- 2 - tramvaj
+- 3 - autobus MHD
+- 4 - příměstský autobus
+- 5 - noční autobus
+- 6 - noční tramvaj
+- 7 - náhradní doprava
+- 8 - lanovka
+- 9 - školní spoj
+- 10 - spoj pro lidi s hendikepem
+- 11 - smluvní spoj
+- 12 - loď
+- 13 - vlak
+- 14 - náhradní autobus za vlak
+- 15 - náhradní tramvaj
+- 16 - noční příměstský autobus
+- 17 - ostatní
+- 18 - trolejbus
+
+## Typ vozidel podle GTFS
+- 0 - tramvaj, podle MPV 2, 6, 15
+- 1 - metro, podle MPV 1
+- 2 - vlak, podle MPV 0 a 13
+- 3 - autobus, podle MPV 3, 4, 5, 7, 16 
+- 4 - loď, podle MPV 12
+- 7 - lanovka, podle MPV 8
+- 11 - trolejbus, podle MPV 18
+- 1700 - smíšený nebo neznámý, nemapujeme z MPV

package/package.json

@@ -0,0 +1,93 @@
+{
+    "name": "@golemio/public-transport",
+    "version": "0.1.0",
+    "description": "Golemio Public Transport Module",
+    "main": "dist/index.js",
+    "types": "dist/index.d.ts",
+    "scripts": {
+        "build": "rimraf ./dist && tspc -p ./tsconfig.build.json",
+        "build-minimal": "run-s 'build -- --sourceMap false --declaration false'",
+        "build-watch": "run-s 'build -- --watch --preserveWatchOutput'",
+        "refresh-precomputed-tables": "cross-env NODE_ENV='test' TZ='UTC' ts-node -r tsconfig-paths/register -r dotenv/config test/scripts/refresh-precomputed-tables.ts",
+        "prepare-db": "golemio import-db-data && run-s \"refresh-precomputed-tables\"",
+        "test:debug": "run-s 'test -- --inspect-brk=9230'",
+        "test:only": "cross-env NODE_ENV='test' TZ='UTC' mocha --exit --check-leaks --timeout 120000 --reporter-option maxDiffSize=0 -r ts-node/register -r tsconfig-paths/register --file 'test/setup.ts' -r dotenv/config 'test/**/*.test.ts'",
+        "test": "run-s prepare-db test:only",
+        "apidocs-test": "npm run apidocs-test-output",
+        "apidocs-test-input": "cross-env NODE_ENV=test golemio swagger api-test --oas docs/openapi-input.yaml --script test/api-docs/input-gateway/server.js --filter test/api-docs/input-gateway/portman-filter.json",
+        "apidocs-test-output": "cross-env NODE_ENV=test golemio swagger api-test --oas docs/openapi-output.yaml --script test/api-docs/output-gateway/server.js --config test/api-docs/output-gateway/portman-config.json",
+        "coverage:only": "nyc --reporter=text --reporter=lcov run-s 'test:only -- --reporter min -r source-map-support/register'",
+        "code-coverage": "run-s prepare-db coverage:only",
+        "format:check-staged": "pretty-quick --staged --pattern '**/*.ts'",
+        "generate-docs": "typedoc --out docs/typedoc src",
+        "lint": "eslint --cache \"{src,test}/**/*.ts\"",
+        "validate-dependencies": "dependency-cruiser --config .dependency-cruiser.js src"
+    },
+    "keywords": [
+        "golemio"
+    ],
+    "author": "Operator ICT, a.s.",
+    "license": "MIT",
+    "repository": {
+        "type": "git",
+        "url": "https://gitlab.com/operator-ict/golemio/code/modules/public-transport"
+    },
+    "engines": {
+        "node": ">=24.0.0",
+        "npm": ">=11.0.0"
+    },
+    "devDependencies": {
+        "@apideck/portman": "1.29.3",
+        "@commitlint/cli": "^11.0.0",
+        "@commitlint/config-conventional": "^11.0.0",
+        "@golemio/cli": "1.11.2",
+        "@golemio/core": "3.4.0",
+        "@golemio/db-common": "1.2.2",
+        "@golemio/eslint-config": "1.1.4",
+        "@swc/core": "^1.15.10",
+        "@types/chai": "4.2.3",
+        "@types/chai-as-promised": "7.1.2",
+        "@types/mocha": "^10.0.10",
+        "@types/node": "^24.12.4",
+        "@types/pg-copy-streams": "^1.2.5",
+        "@types/sinon": "^9.0.10",
+        "@types/supertest": "^2.0.10",
+        "body-parser": "^1.20.3",
+        "body-parser-xml": "^2.0.5",
+        "chai": "4.2.0",
+        "chai-as-promised": "7.1.1",
+        "cross-env": "^7.0.3",
+        "dependency-cruiser": "^17.3.3",
+        "dotenv": "^8.2.0",
+        "eslint": "^8.1.1",
+        "husky": "^4.3.7",
+        "mocha": "^11.7.5",
+        "npm-run-all": "^4.1.5",
+        "nyc": "^17.1.0",
+        "prettier": "^2.5.1",
+        "pretty-quick": "^3.1.0",
+        "rimraf": "^3.0.2",
+        "sinon": "^9.2.3",
+        "source-map-support": "0.5.21",
+        "supertest": "^6.0.1",
+        "ts-node": "^10.9.2",
+        "ts-patch": "^3.3.0",
+        "tsconfig-paths": "^4.2.0",
+        "typedoc": "0.28.19",
+        "typescript": "^5.9.3",
+        "typescript-transform-paths": "^3.5.5"
+    },
+    "peerDependencies": {
+        "@golemio/core": "^3.0.7-dev.2 || ^3.1.0-dev.2 || ^3.0.0"
+    },
+    "dependencies": {
+        "@golemio/ovapi-gtfs-realtime-bindings": "1.4.1-dev.2464451735",
+        "@turf/turf": "^6.5.0",
+        "cheap-ruler": "^3.0.2",
+        "csv-parser": "^3.0.0",
+        "csv-stringify": "^5.6.2",
+        "fast-xml-builder": "^1.1.5",
+        "html-entities": "^2.6.0",
+        "pg-copy-streams": "^7.0.0"
+    }
+}