Refactoring fast transportation to properly support traffic_model

[arnasbr]

Current implementation of traffic_model is not actually working, because it should be nested inside the transportation object. This PR is attempting to fix that.

It makes 2 breaking changes, illustrated here #193 (comment), with the goal of making fast endpoints more similar to the regular ones (and more extensible)

My question for the reviewers - do you think it's worth keeping backwards compatibility for:

1. The old way of setting transportation mode on fast endpoints using the enum
2. The old way of setting traffic_model (I can even make it actually work with custom json encoding)

If we do keep backwards compatibility for both, there can be weird scenarios where the user specifies traffic model in both the OLD and NEW ways, so at most I'd support #1 but not #2. Ideally neither

[Donatas-L]

This PR will resolve: #184

[Copilot]

Pull request overview

This PR refactors the “fast” request models so traffic_model is correctly nested under the transportation object (matching the API schema) and aligns fast endpoint request shapes more closely with the non-fast endpoints.

Changes:

• Replace the fast-endpoint transportation enum + custom serializer with dedicated *Fast transportation BaseModels (with traffic_model on driving types).
• Update fast request models (time_map_fast, time_filter_fast, h3_fast, geohash_fast) to accept the new transportation objects.
• Update tests, benchmarks, and an example to use the new transportation object API.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
traveltimepy/requests/transportation.py	Introduces *Fast transportation models and renames the old fast enum.
traveltimepy/requests/time_map_fast.py	Switches transportation field to a union of new fast transportation models.
traveltimepy/requests/time_filter_fast.py	Switches transportation field to a union of new fast transportation models.
traveltimepy/requests/h3_fast.py	Switches transportation field to a union of new fast transportation models.
traveltimepy/requests/geohash_fast.py	Switches transportation field to a union of new fast transportation models.
tests/time_map_fast_test.py	Updates usage to new transportation objects; adds/updates traffic model tests.
tests/time_filter_fast_test.py	Updates usage to new transportation objects; adds/updates traffic model tests.
tests/h3_fast_test.py	Updates usage to new transportation objects; adds/updates traffic model tests.
tests/geohash_fast_test.py	Updates usage to new transportation objects; adds/updates traffic model tests.
examples/time_filter_fast_matrix.py	Updates example to new PublicTransportFast() usage.
benchmarks/time_filter_fast.py	Updates benchmark to new transportation objects (currently uses ferry type).

Comments suppressed due to low confidence (1)

traveltimepy/requests/transportation.py:75

• TransportationFastType is no longer referenced by any fast request models (they now take PublicTransportFast/DrivingFast etc.), so this enum becomes dead API surface and also breaks existing imports of TransportationFast. Either remove it entirely, or keep a backwards-compatible alias/name (e.g., keep TransportationFast as a deprecated alias) and/or accept the enum in the fast request validators if you want to support the old calling style.

class TransportationFastType(str, Enum):
    PUBLIC_TRANSPORT = "public_transport"
    DRIVING = "driving"
    CYCLING = "cycling"
    WALKING = "walking"

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gergelytraveltime]

LGTM other than the comments. I think, that if we release a new version with a breaking change, it could be acceptable, as the user can still use the older version (maybe that we need to release bugfixes for older versions, and then the users would like to avoid the breaking changes).

[arnasbr]

Decision has been made to accept this breaking change, will document it in the release