fast travel cleaners tech-debt

[ethan-moss]

Fast travel tech-debt raised during PR #125, associated with cleaners.py:

1. Refactor clean_multiple_stop_fast_travel_warnings() and clean_consecutive_stop_fast_travel_warnings() into a common cleaning function:

   • Methods are similar, just the warning message and impacted tables are different.

2. filter_gtfs_around_trip() units optional argument should be "km" - or take from gtfs.feed.dist_units <--- probably best approach.

3. Use pd.isna() in filter_gtfs_around_trip() - handles strings, no need to try/except.

4. Add a unit test for _gtfs_defence() in the passing case (i.e. using a GTFS test fixture)

5. For _add_validation_row() add defence to ensure message is only either {"warning", "error"}

6. drop_trip() works with trip_ids that aren't in stop_times. This is OK since no cleaning is done, but it's slightly opaque for public function, maybe we can protect against this? Perhaps raise a warning to say not cleaning since no warnings/no valid trip_ids?

Points 3,4,5 & 6 resolved in #254

7. Develop a unit test for the default speed bounds return statement (when the route_type is not a SPEED_BOUNDS key):
   • modify the GTFS fixture, perhaps replacing the route_type for a trip with a different value?

[CBROWN-ONS]

26/10/2023
I have decided than point 1 won't be implemented. This is because it impacts the structure of the pipeline. Instead the beginning of both functions will be functionalised.

[CBROWN-ONS]

Points 3, 4, 5, 6 will be completed in a separate PR to #195 (#254)

[r-leyshon]

Migrated to datasciencecampus/assess_gtfs#10