Skip to content

Public transit router #10

@munterfi

Description

@munterfi
  • Graph of routes which touch each other. (Possibly also direction and time).
  • Then routing in the graph from connected routes which are sorted by number of transfers in ascending order.
  • If there is a possible connection due to connected routes:
    • Play through legs of routes, missed connection? --> break
    • Connection then consists of legs, always store the availabilities on the legs.
  • Reservation then also contains the same legs. Customer_id and reserved seats are then stored on the reservation. Possibly legs can be flown which do not need a reservation (but this would require a flag already on trips).
  • Stops need not only travel time to the next but also layover time --> allows more transfers
    • stop->time_at_stop
    • stop->time_to_next
  • Attention: Question is still, where to change at parallel!!!?
    • The graph must store the transfer node, the direction doesn't matter, because transfers are always possible in both directions. How must this be mapped.
    • Always use the first possibility for transfers.
    • This means however a restriction in the possible reservations, since not on other combinations one looks. (Tasks for the future...)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions