Create backend endpoint that creates trip emissions for every transportation type

[codingfabi]

To enable planning of business or computing trips, we should create a single endpoint that returns the emissions for a trip for every avaible transportation type.

A possible structure of the result would be:

assumedEmissions { "car": 300, "plane": 3000, "train": 30 }

We could currently do this by sending a single request for every transportation mode but this would cause a lot of traffic and can be simplified.

[redfrexx]

The request can currently be sent using a new endpoint. The options are the same as for business trips.

To reduce traffic it is possible to send multiple queries in one request. They just need to be named differently, e.g. option1, option2 in the following example.

Is this fine?

Request:

mutation planTrip {
    option1: planTrip (input: {
      transportationMode: "Car"
      distance: 200
      size: "Medium"
      fuelType: "Gasoline"
      passengers: 1
      roundtrip: false
    }) {
        success
        message
    	co2e
      }
    option2: planTrip (input: {
      transportationMode: "Car"
      distance: 200
      size: "Large"
      fuelType: "Gasoline"
      passengers: 1
      roundtrip: false
    }) {
        success
        message
    	co2e
      }
}

Response:

{
  "data": {
    "option1": {
      "success": true,
      "message": "success",
      "co2e": 46.2
    },
    "option2": {
      "success": true,
      "message": "success",
      "co2e": 62.2
    }
  }
}

[codingfabi]

This looks good and will be fine for now :)

A much needed improvement would be the possibility to provide a start and end address instead of just the distance. Especially since the distances will be different for every transportation mode.
Can we alter the endpoint s.t. it works with start and end addresses as well (just like we had planned for the business trip entities)? Or are we depending/being blocked by the open rout service at this point?

[redfrexx]

Theoretically you can already specify a start and end address, it will just throw an error atm because we still need to update the co2calculator package. ^^ The possible parameters are the same as for business trips. I've added them to the documentation.

[codingfabi]

Questions/Bug Collection for the backend endpoint:

• When requesting emisisons for a transportation mode with a distance, the backend returns the following error:

{ "success": false, "message": "local variable 'stops' referenced before assignment", "co2e": null, "__typename": "PlanTrip" }

I think this is some problem in the calculator package as this is the only place where we use a stops variable. Anyhow, I was not able to locate the exact problem.

• When requesting emissions for transportation mode plane with any seeting class, the backend returns a 400 error with the following message:

{ "message": "could not convert string to float: 'economy class'" }
Is the seating class not supposed to be a string but a number?

[redfrexx]

I've fixed the seating class error and it is now also possible to provide start and destination addresses in the query (see this query for example).

I wasn't able to reproduce the "local variable 'stops' referenced before assignment" error. But maybe this is already fixed now, because I've update the co2_calculator package in the backend with the latest changes from main. It is however not set to the main branch yet, since I had to make some temporary adjustments in the co2_calculator code to make things work. So I've created a new branch called dev-trip-planner which is used in the backend for now.