CRAG accounts

Functionality available to the user

A drupal user can create one or more named carbon accounts for him/herself or anybody else. By default the name of the account defaults to the name of the drupal user.

1. When the account is being edited, the user can various kinds of carbon debit such as meter readings, trips by car, trips by air etc, in fact any source of emission that has been configured by the admin or another person configured with the appopriate role.

Every new source of emissions can be placed into its own group. By default all emissions will go into a single group called 'My emissions'. But when a user first enters a gas meter reading or other carbon debit, s/he might choose to call the group '122 Alexander Road' instead.

2. When the account is being edited subsequently, users will see previously added emissions in each displayable/hideable group (same as now except determined by the user). So a user might have these created these groups:

122 Alexander Road gas
122 Alexander Road electricity
Trips to work in the Toyota
Trips to work in the Volvo
Trips to work by train
Trips by air

A user can add one (or possibly more) carbon debits to an existing group using one (or more) set of blank fields in each group.

However the user is only able to enter limited data for each subsequent carbon debit such as the date and, say, the distance travelled. User are not prompted for units or other information car size/fuel but this is displayed underneath the box collecting the number. This is done to save screen space and make it visually simpler for quick updates.

3. All the carbon debits are saved together when the carbon account editing is completed by pressing the submit key. (It is intentional to allow the user to add multiple carbon debits on one single form so the user update his/her debits in the shortest possible time.)

Users are able to include emissions from groups that are made shareable (e.g. Dave and Sue might share the same house and so make 122 Alexander Road a shared debit).

There is no support to allow someone to record a complicated journey that involves multiple modes of transport. You would have to add each section of the jounrney e.g. bus into central Berlin would have to be added to the other bus trips which may all be trips into central Birmingham

4. When the account is being viewed, each carbon debit (and any carbon credits) will be listed, along with the date, amount etc. (Not sure how consumption from meter readings will be shown yet.)

Functionality available to the carbon accontant

>David: I guess this annual group
>footprint could be stored in a separate groups table. We could do this
>in a third module og_carbon - so your other two modules could be used
>for either user-centric or group-centric sites.

5. The accountant is able to view all accounts, and all the accounts in a given group (if user has specified on). Each individual account occupies one row on the page and the total of the carbon debits and credits in Kg is displayed. (TODO)

6. Like the user, the accountant is able to add carbon debits to any one account but more importantly s/he can also add credits on any date along with some comment (e.g.'annual quota' or 'paid off'). (TODO)

7. The accountant is able to add, edit and delete new sources of emissions. Each source of emission has a class that defines how the CO2 is calculated. The initial two classes are expected to be:

a) 'simple' - This class will simply take the number entered by the user and multiply it by an editable conversion factor.

b) 'climatecare' - This class implements teh climate care flying algorithm which takes into the fuel required for take off and landing.

> David wrote:
> Linear interpolation? Given seasonal variation in energy use, this could
> break down if meter readings are not sufficiently regularly spaced (e.g.
> several readings, but only in winter, would vastly overestimate annual
> footprint), so may need to specify a minimum resolution and spacing of
> meter readings.

> Have you thought about how to interpolate between the data
> points? This will be necessary for the "accountant layer" to determine
> footprints for any period (given variable entry dates for meter
> readings).

(David i am going to use a simple algorithm to select data points that are closest to the start and end point.) There does need to be configurable limits. Open to suggestions on algorithm.

Later, more complicated classes can be added to calculate emissions e.g. air travel between 2 cities. (I am not going to do this.)

Design

The drupal carbon module defines three types of drupal node.

carbon footprint

The carbon_footprint drupal node is loaded and saved from the carbon_footprint table by drupal's core routines. It contains the name of the footprint and preferences but data related to energy or CO2.

Each debit/credit is represented by carbon_stamp, another drupal content type and is saved in the carbon_stamp table.

Each carbon_stamp is attached to one or more carbon_footprint. The joins between the carbon_stamp and carbon_footprint tables are held in the table carbon_stamp_footprint.

Users can share their footprint with their friends. Their friends' uids are held in the table carbon_footprint_share.

carbon source

Every type of source of emissions is represented by a drupal node. The drupal node is loaded and saved from the carbon_source table by drupal's core routines. Conversion factors, descriptions and units for each type of emission e.g. 'small car', 'miles' are held in that node.

Users with appropriate access are able to create,edit and delete new sources.

Each type of emission is associated with a named class e.g. simple or chooseclimate. This class is responsible for implementing methods that, for example, convert miles to CO2 emissions.

Each type of emission will be given some kind of unique short code like 'ELEC' by the person creating the source.

Each type of emission can be given a different model name such as 'CRAG' or 'carbon coach'. This means that curious invididuals can create two carbon footprints using different models but use the same underlying data as long as both models use the same codes for the different sources. The model on any carbon footprint can be changed at will.