pledge4future / co2calculator Goto Github PK

If the user does not know how many kilometers a train ride contained, is there a way to calculate this for the user if they provide us with the start and end point?

Transform existing print statements with "Warning" to actual warnings:

import warnings
warnings.warn("Warning message")

and add new warnings for the case that the user did not provide certain parameters and a default value is used.
(see issue #43 )

The calculation of the annual or monthly emissions for heating, electricity and business trips is done outside of this package, but the commuting emissions are not. To keep it consistent I would suggest to remove the computation of the annual commuting emissions from this package. So just removing this line:

Use OpenRouteService to query the coordinates of airports with a given IATA code and train stations with a given address (geocoding).

@redfrexx Do you think we can get a Pledge4Future ohsome API key?

Instead of using one of the predefined emission factors, users can also put in their specific fuel consumption (e.g., if they track it themselves).
We should implement this.

• get manufacturing emissions separately
• calculate emission from the exact fuel combustion (needed: emission factors for the fuel combustion)

Desgin an uncertainty score for the data put in by the users. Were average values used all the time or were more specific values (e.g., fuel type, size class, etc.) used?

Figure out which data should be retained in the database so that the score could be recalculated later. Right now we try to store as less data as possible so that we don't run into data privacy issues

Most of the business logic is designed to calculate distance and emissions from relatively low-level functions in one go. This makes it really hard to test and maintain. Also, it is prone to human error when editing code.

Calculating distance and calculating emissions should be clearly separated. Function names should be as precise as possible. All emission calculation functions should only accept distance, no stops etc.

Accepted when:

• Functional testing of backend calls is implemented (to ensure integration safety with backend)
• Dedicated functions to calculate distance from stops, start-destination, .. are implemented (and tested)
• Used interfaces of backend code is refactored to use new distance-functions, then call emission calculation

Side effect:

• Code is refactored to DRY principle

We do not have emission factors for hybrid cars. Would we awesome if we find any, because there are quite a lot of plug-in-hybrids in Germany.
Alternative: use gasoline emission factors for plug-in hybrids?

Integrate OpenRouteService-API to query road/train distances between given locations.
https://api.openrouteservice.org/

Model TransportationMode was introduced in #81. Use it in the complete code base (calculate.py, distances.py)!

Implement the function calc_co2e_businesstrip:

We still need a methodology for air travel emissions.

Here some references:

• myclimate (https://co2.myclimate.org/de/flight_calculators/new).
  • Methodology including formula and references: https://www.myclimate.org/fileadmin/user_upload/myclimate_-_home/01_Information/01_About_myclimate/09_Calculation_principles/Documents/myclimate-Flugrechner-Grundlagen_DE.pdf
• UBA co2 calculator - KlimAktiv and ifeu (https://uba.co2-rechner.de/de_DE/mobility-flight#panel-calc)
  • two modes (general and detailed)
• atmosfair (https://www.atmosfair.de/de/kompensieren/flug/)
  • documentation: https://www.atmosfair.de/wp-content/uploads/flug-emissionsrechner-dokumentation-berechnungsmethode-1.pdf
• Jardine, C. N. (2009: Calculating The Carbon Dioxide Emissions Of Flights. Environmental Change Institute, Oxford University Centre for the Environment, Exford. URL: https://www.eci.ox.ac.uk/research/energy/downloads/jardine09-carboninflights.pdf

Add a descriptiong of how others can contribute to the project to the README.

• How to create pull requests
• How to run tests
• How to use pre-commit hooks

def calc_co2_commuting_per_mode(transportation_mode, distance=None,
                          size=None, fuel_type=None, occupancy=None, passengers=None, work_weeks=None):
    """
    Calculate co2 emissions for commuting per mode of transport (not implemented yet)
    :param transportation_mode: [car, bus, train, bicycle, pedelec, motorcycle, tram]
    :param distance: distance in km per week
    :param size: size of car or bus if applicable
    :param fuel_type: fuel type of car, bus or train if applicable
    :param occupancy: occupancy, if applicable/known (only for bus)
    :param passengers: number of passengers, if applicable (only for car)
    :param work_weeks: number of working weeks per year,
                e.g., 52 (weeks per year) - 4 (paid leave) - 2 (public holidays) = 42
    :return: total emissions for the respective mode of transport
    """
    pass
    return 999

Might have to be adapted, if calculating on a monthly instead of yearly basis..

Use sphinx to automatically generate a documentation for our package, so we do not have to document everything in the markdown and update it there.

• Update documentation in repo
• Update documentation in webpage (WePledge)
• Deploy to Read The Docs (see https://coderefinery.github.io/documentation/rtd/ and https://docs.readthedocs.io/en/stable/intro/import-guide.html)?

Some things discovered when writing unit tests so far:

• A lot of repeated code for distance and emission calculation (hurting DRY principle)
• Methods often have too many arguments
• Arguments are often not validated inside a method (hence, likely to crash)

Mitigations:

• Use enums instead of lists of strings to declare types (e.g., transportation_mode)
• Implement models for input and output including validators (with the help of pydantic)
• Implement models for complex arguments including validators (like stop)

So far, the methods often return emissions and distance. Since all methods are now distance-based only (from #81), we only need them to return emissions.

Figure out how we could run the tests involving a request to the openrouteservice in the automated tests run on github.

Often, electricity and heating consumption will only be available on the building level. Therefore, it is important to know what area the lab occupies to obtain the lab's consumption.

heating emissions = energy consumption for heating of building * share of floorspace of lab * emission factor

The user can then either directly provide the share of floorspace or both the floorspace of the lab and the entire floorspace of the building.

Currently, our geocoding function looks like this:

def geocoding(address):
    """
    Function to obtain coordinates for a given address
    :param address: Location/Address to be searched
            user should give address in the form:
            <adress>, <locality>, <country>
            e.g. Hauptbahnhof, Heidelberg, Germany
            e.g. Im Neuenheimer Feld 348, Heidelberg, Germany
            e.g. Heidelberg, Germany
    :return: Name, country and coordinates of the found location
    """

    clnt = openrouteservice.Client(key=ors_api_key)

    call = pelias_search(clnt, address)
    for feature in call["features"]:
        name = feature["properties"]["name"]
        country = feature["properties"]["country"]
        coords = feature["geometry"]["coordinates"]
        break

    return name, country, coords

->

This means that from a (potentially very long) results list, we simply choose the first one, which will often be wrong.
Here, we need a good solution, e.g.

• display all results to user in a list and let him choose the correct one
• use autocomplete pelias geocoding (https://github.com/pelias/documentation/blob/master/autocomplete.md)
• use structured geocoding instead (if it even works better?) ->

  co2calculator/co2calculator/distances.py

  Line 92 in 68ee5e3

  def geocoding_structured(country=None, locality=None, zip_code=None, address=None):

• ...

For transport_mode=car calc_co2_commuting returns a tuple (emissions, distance),

co2e = calc_co2_commuting(transportation_mode="car",
                                     weekly_distance=distance,
                                     passengers=1,
                                     size="medium",
                                     fuel_type="gasoline")

but for transport_mode=bike a float value emissions.

co2e = calc_co2_commuting(transportation_mode="bicycle",
                          weekly_distance=distance)

I guess it would be best, if it always returns a tuple (emissions, distance).

• Fix currently open issues - (see milestone)
• update documentation
• merge dev into main
• go public :)

Document the methodology in the markfown file

• Installation of requirements (README.md)

• Documentation of geocoding of train stations

• Documentation of warnings

• Usage of default parameters

• Update documentation in frontend. Create a branch from https://github.com/pledge4future/WePledge/blob/demo/demo/src/views/markdowns/methodology.md

• Update figure https://github.com/pledge4future/WePledge/blob/demo/demo/public/static/images/methodology.png ; drawio files are here: https://drive.google.com/drive/folders/1AKdDwfeG_Ds5JmEzOjhVEGo5v13ETZGQ

Adapt the preprocessing script and enums in constants.py so that:

In emissions_factors.csv: value with underscore and lower letters, e.g. "heat_pump_air"
Enums in constants.py: Human readable strings, e.g. "Heat pump air"

As discussed in Slack, co2calculator aims for users of python 3.9 and above. Hence, we remove 3.7 and 3.8 from the CI tests!

How to handle or store multi-modal business trips?

• in graphql
• in the data base
• in the form

Implement pre-commit hooks to ensure code style

• black
• flake8
• Add contribution section to readme and descibe set up of pre-commit hooks.

Check the final methodology with IFEU and MPIA to make sure it's valid.

In many (esp. academic) institutions, there will be lectures, events, hosted conferences, etc., which can often produce high amounts of emissions but also include external people.

We should include such events in the calculator (consider in completeness score?), and think about how to account for it:

• Do we distribute it on all participants (incl. externals) and then only count the emissions of internals to the institution's emissions?
• Do we also store such "external/guest's emissions" for each institute (separately for the other emissions)?

There might be transport emissions which are covered by neither of the categories "business trips" and "commuting".
Those include the emissions related to vehicles operated by the lab. This may usually be an institute car or bus, but depending on research area could also be a ship or helicopter.

General formula:
Emission of a vehicle operated by the lab = annual quantity consumed of the energy source used * emission factor of the source concerned.

The quantity consumed may be expressed in km traveled, flight hours, liter consumed or sea-days.

See also: https://labos1point5.org/ges-1point5 -> La méthodologie -> Méthods de calculs

Since 2020, many people are working in home office. Therefore, some electricity consumption will not be accounted for if only using the institution's building electricity consumption.

We should have an option to also count emissions in home office.

This may be calculated by the device(s) used in home office and the duration of daily/weekly usage. Lighting is also important and heating (you usually don't heat your home while you are at work).

The heating emissions in home office could be estimated in the following way: monthly heating consumption / number of people in the household * share of the month spent working at home

Context:

• Streamline different methods of distance calculations
• Avoid loading DataFrame|s as global vars
• Make it a "Service"
• Define clear interfaces

The following code fails with unsupported operand type(s) for /: 'float' and 'NoneType' when the argument passenger is not given.

co2e = calc_co2_commuting(transportation_mode="car",
                                 weekly_distance=20,
                                 size="medium,
                                 fuel_type="gasoline")

I think it would be good to either set a default value (e.g. 1) or raise an AssertionError at the beginning of the function. Would be good to check if other combinations of arguments cause similar errors.

Integrate the MyClimate-API to the co2calculator for calculating flight emissions.
https://connect.myclimate.org/apis#operation/post-v1-flight_calculators.json

We could add a section for

• electronic/research devices (new acquisitions, inventory)
• paper (office paper, possibly also toilet paper etc.)

doesn't contribute massively to emissions, but maybe add water consumption as well

Emissions from bus travels highly depend on the occupancy (i.e. what % of seats are occupied).
Below are some figures demonstrating this (data downloaded from probas database, can be found in data/probas/bus.
We should therefore also ask the user for an estimate on bus size (3,5-18 t or 18-30 t) and occupancy (i.e. almost empty (20%), half full (50%), almost full (80%), full (100%)). Most will not be able to answer this, where we can use the one with average size and occupancy of 50 %.

Some of the tests are actively calling openrouteservice - which is not really a good practice for unit or functional testing.
Those interfaces shall be mocked. If - for any reason - those calls are really wanted, those tests should be moved to proper integration tests.

We currently have tests in calculate.py using data from external .csv-files.

We should rewrite them to unit test into a file "testing.py".

For computing the commuting emissions, we need emission factors for:

• E-bike (currently only: Pedelec)
• Hybrid cars
• Scooter
• Motorcycle
• Tram
• Urban bus
• Local train
• Metro

For business trips, we might add:

• boats/ships (e.g. ferries) -> find out detour coefficient??
• different types of planes?

We already have a couple of enums defined in constants.py, but they do not seem to be used.
Similarly to issue #84 / PR #87: Use them in calculate.py

Background:

Users will not know the adress of the stations, but currently our geocoding service needs an address. Check if there is an API that links the train stations to the addresses.

Each trip should be categorized into: ["regional", "national", "continental", "overseas"] ?

Create fake data for testing purposes and upload/edit here: https://github.com/pledge4future/co2calculator/tree/dev-fakedata/data/test_data_users
@veitu @nkrasovec @han16nah

Heating consumption can be given in differnet units based on the type of the heating (oil, pellets, etc.). So we need to implement the conversion to kwh.