Support for Netex extensions to Stop and Stations  #2813

GTFS have a stop hierarchy with Stop and Station. It is strictly 2 levels, other locations types are not relevant for this issue.

In Netex, Nordic profile(Transmodel) we have Quay, StopPlace and GroupOfStopPlaces. A StopPlace can be Mulitmodal or Monomodal.

To support Netex stops we need to extend the OTP internal domain model and the API model. We DO NOT need to enforce all the business rules for Netex and GTFS, just make sure we can represent both models and that the API stays backward compatible. Business rules that are not relevant to OTP should be optionally validated at data import time, not by the internal model.

Short description for Netex elements

See Stops - Netex, Nordic profile for a detailed description.

Today transit routing is only allowed between stops/quays (same for GTFS and Netex). There might be a good reason to assign a bus or tran alight/boarding to a Station, like before a train or bus is assigned a stop/quay, but we leave that to another issue.

Netex have a richer hierarchy of stops that GTFS. OTP do not need to enforce the stop business rules, only support sensible business logic to allow routing and allow clients to be able to browse the GTFS/Netex model to be able to visualize logic/icons for travel results and drawing maps with icons.

Use cases where Stop and Stations are important

1. Routing
   1. Transit routing - In transit routing we only care about Stops/Quay. No change needed to support Netex. The initial time/cost may differ for each initial stop/quay(access & egress).
   2. Transfers are always between Stops/Quays - no change.
   3. Access/Egress search from/to Station(StopPlace):
      1. Use all Stops/Quays (any level) in the hierarchy below the Station.
      2. Today the initial time/cost is 0 in OTP when we search from Station using its ID, with a fallback on coordinates if the ID is not found.
   4. Access/Egress search from/to GroupOfStopPlaces is done exactly like StopPlaces using the set of all quays from underlaying StopPlaces.
2. Describing the itinerrary. It should be possible for the clients to navigate the stop hierarchy and determine the category (Quay, Monomodal, Mulitmodal, GoSP) and fields, possibly having specific types for each of them.
   1. An important decision here is to decide if Netex elements should be visible at all in the "GTFS" version of the API (GraphQL API) or not.

Version of OTP used

OTP 2 dev-2.x

Design

Since the functionality is exactly the same for Station (GTFS) and MonomodalStopPlace, MulitmodalStopPlace, and GroupOfStopPlaces (Netex) we can use just 2 types in the internal model of OTP: Stop and Station. We add a category field to Station. It should be set in the import and used by the API - ONLY. A Station have a set of quays and a set of child stops, and an optional parent. There is no need to set any restrictions on the number of nesting levels in the hierarchy.

If there at a later point in time becomes necessary to logically treat the Station categories differently, that should trigger a refactoring with more types.