Separate generic data model from agency data model in trip linking / tour building

[nick-fournier]

I'm wanting to contribute to this but I'm wondering what people's thoughts on making this repo an installable package with tools that can be used individually rather than as a set daysim prep pipeline.

I propose separating the applied project specific scripts from the generic tools source code. Typically this is done with a src folder and a scripts folder. The core processing tools, like trip linking could/should be robustly unit tested to handle weird edge cases as they arise.

That way it could be easily imported and used in different analyses with comparable results both in this repo and elsewhere? @FlaviaTsang

something like....

from traveldiarytools import LinkerTinker

unlinked_trips_with_linked_trip_id, unique_linked_trips = LinkerTinker(
    unlinked_trips = trips_df,
    change_mode_code=11,
    transit_mode_codes=[12, 13, 14],
    max_dwell=120,   # max time between linked segments
    dwell_buffer=100 # max meters between linked segments
)

I'd be happy to set that framework up.

EDIT:
I don't have write access to this repo so I made a fork to do my work and make a PR.

[FlaviaTsang]

I like the idea of making the magic numbers explicit, and disentangling the Daysim-specific processing from the cross-agency processing is definitely one of our goals.

On the magic numbers, I've been thinking that moving all of them into the .toml files would be the way to go. We already have a config folder and a survey_processing folder, and store settings in .toml files.

If there are additional benefits to turning this into an installable package, I’d be interested to hear more.

[lmz]

@nick-fournier - RE: I don't have write access to this repo so I made a fork to do my work and make a PR.
Ideally you'd make a branch in the BayAreaMetro fork (https://github.com/BayAreaMetro/travel-diary-survey-tools) for your work, in case we have internal collaboration within MTC. 😄

[nick-fournier]

Oh i see, awesome. I can do that.

[lmz]

cc @Ennazus @sdrewc

[FlaviaTsang]

cc @sdrewc

[sdrewc]

@nick-fournier definitely we want to move from daysim-specific to generic and configurable. I think your suggestion (and @FlaviaTsang 's) aligns with that.