📌 Problem

The current Travel module data is incoherent compared to other modules, because it mixes Plane and Train data that are in different formats.

• The datasets are not in the same formats, do not use the same emission factors. Back Office treats them differently (2 rows)

• But The module UI treats them as a single table

➡ Result: Inconsistent architecture.
This creates confusion / incoherence with other modules.

💡 Proposed Solutions

✅ Option 1 – Split into 2 Submodules (Recommended)

Separate the Travel module into 2 submodes (comme IT Equipments and Scientific Equipments) : Plane Trips & Train Trips - which can each have their own specific columns and their own emission factors.

• Back Office / Data Management : 2 lines for trains and planes, as requested per @martina-gallato
• Travel Module : 2 distinct tables, with their own "Upload CSV" by the user.

+ Benefits: Data formats of trains and plane can differ. Cleaner data structure & Better scalability

( Recommended by IT4R and @martina-gallato )

⚖️ Option 2 – Keep a Single Submodule (Requires Data Harmonization)

Merge Plane and Train datasets in a single submodule, making all columns consistent (Unified schema for planes and trains)

• Back Office / Data Management : A single line to upload both planes and trains. Must merge emission factors
• Travel Module : Samesame. Upload CSV button can mix planes and trains - we add the column "transport_mode"

🤯 Option 3 : Current Situation (inconsistent)

There is a structural inconsistency between Back Office and Module behavior:

• Back Office / Data Management : Trains and planes Treated as 2 submodules (@martina-gallato requires 2 separate lines to upload data and emission factors)
• Travel Module : Treated as 1 single submodule, since you wanted all trips in one table. -> It's a problem for users uploading CSVs because it's not the same CSV upload for planes and trains !

-> Fyi, it's not impossible to keep it as is. It's always possible to "hack" if you really want to keep it as is, according to your current specs, but it will be less consistent/elegant for future developers/institutions to pick-up this project and understand this choice.

❓ Clarifications needed

Pinging you @agletiec (en tant que propio de la spec travel) et @CDucrest-EPFL : on aurait besoin de votre optinion sur ce sujet, et de choisir une solution (si on change pour l'Option 1 ou 2, plus élégantes/cohérentes) mais qui impliquent un changement de specs.
Désolée pour le franglais.