tahini
commented
6 months ago Other reasons to implement this:
- Current results take A LOT of space in the database. We had to increase the size of the database multiple times in our infra, following large calculations with alternatives.
- Evolution will also require this data in the validations. In this last case, Transition will not be part of the equation, the transition db tables will not be present, the results may even come from GTFS, so the case in the description of the foreign key to objects does not apply.
We will have to make sure that Transition can link those results to its data eventually, without forcing the referencing. And that Evolution can make proper use of the data in various cases (validations post-survey or during survey, calculations, etc)
619 saved the raw results as a json object to the database, from which the various outputs can be generated. Eventually, for easier result management, indicator calculations, etc, results should be saved differently, with actual fields and correct types.
@kaligrafy suggested to save for each trip/mode/alternatives the various steps of the route to take, as a trip can be seen as a sequence of segments (walk to ..., take vehicle X to ..., etc). With foreign keys to the transit objects (eg, schedule trips and/or paths).
From this, the result outputs can be generated on demand (for example csv files, detailed csv, geometries, etc), but Transition could also compute some indicators from those results, etc.
This will require some versioning of the transit objects. If a schedule or path used by the calculation is changed after the results have been calculated, they should be invalidated.