INTERGOVERNMENTAL PANEL ON CLIMATE CHANGE
WMO

NATIONAL GREENHOUSE GAS INVENTORIES PROGRAMMEESTABLISHMENT OF A DATABASEON

GREENHOUSE GAS EMISSION FACTORS

Report of the First Expert Meeting

Paris, France
2-4 July 2001

Supporting material prepared for consideration by the Intergovernmental Panel on Climate Change.
This supporting material has not been subject to formal IPCC review and approval process.

UNEP

IPCC National Greenhouse Gas Inventories Programme
and its Technical Support Unit
The World Meteorological Organization (WMO) and the United Nations Environment Programme (UNEP) jointly
established the Intergovernmental Panel on Climate Change (IPCC) in 1988 to:
(i)
(ii)
(iii)

Make periodic assessments of the science, the impacts, the economics and the options for the mitigation
of/adaptation to climate change;
Assess, and develop as necessary, methods such as the IPCC Guidelines for National Greenhouse Gas
Inventories;
Provide, on request, scientific/technical/socio-economic advice to the Conference of the Parties to theUnited Nations Framework Convention on Climate Change (COP/UN FCCC) and its bodies.

The IPCC, at its 14th session in October 1998, established a Task Force on National Greenhouse Gas Inventories(TFI). The TFI was to have a Task Force Bureau (TFB) to provide guidance on the management of the IPCC
National Greenhouse Gas Inventories Programme (IPCC-NGGIP).
In accordance with a decision taken by the IPCC at its 14th session and an offer of funding by the Government ofJapan, a Technical Support Unit (TSU) for the Programme was set up in 1999 at the Institute for Global
Environmental Strategies (IGES) in Hayama, Japan. The TSU took over the technical support for the NGGIP which
had been managed by IPCC Working Group I since 1991, in close collaboration with the Organisation for Economic
Co-operation and Development (OECD) and the International Energy Agency (IEA).
The objectives of the IPCC-NGGIP are:•••To develop and refine an internationally-agreed methodology and software including good practice guidance
for the calculation and reporting of national GHG emissions and removals;
To encourage the widespread use of this methodology and guidance by countries participating in the IPCC andby signatories of the United Nations Framework Convention on Climate Change (UNFCCC);
To facilitate the compilation of national greenhouse gas inventories.

The primary function of the TSU which is responsible to the TFB through its two Co-chairs is to serve the needs of
the NGGIP.
The TSU undertakes scientific and technological duties as part of the Programme including:-

Improving technical support for countries engaged in estimating GHG emissions and removals related to fuel use,
industrial sources, waste disposal, agricultural activities and land use, land-use change, and forestry;
Collecting, managing and disseminating information related to GHG inventories;
Organising international meetings of experts to take up scientific and technical issues in the various sectors toassist parties compile more reliable GHG inventories;
Responding to specific requests from parties on issues relating to GHG inventories.

February 2001
Japan

ACKNOWLEDGEMENTS
This report was prepared by Tinus Pulles, Katarina Mareckova, Taka Hiraishi, Buruhani Nyenzi and Kiyoto Tanabewith assistance from Jos Olivier, Elizabeth Scheehle, Pavel Fott, Ismail Moula, Pascal Boeckx, Gabriel Hernandez,
Stephanie F. Finn, Mike Woodfield, Chia Ha, Leandro Buendia and Kyoko Miwa. We are grateful to many experts
who contributed to this report and attended the expert meeting. We also thank the staff of the International Energy
Agency (IEA) and the staff of the Institute for Global Environmental Strategies (IGES) who assisted in organising
the expert meeting.

Table of Contents
Summary ................................................................................................................................................1
1. Introduction .....................................................................................................................................3
2. Overview...........................................................................................................................................5
3. Management (discussed by BOG3) ................................................................................................6
3.1 General aspects ............................................................................................................................6
3.2 Database design ...........................................................................................................................7
3.3 Data quality control .....................................................................................................................7
3.4 Database operation/maintenance .................................................................................................8
3.5 Supporting systems to be introduced as resource and time allow................................................8
3.6 Distribution of the EFDB.............................................................................................................8
3.7 Language .....................................................................................................................................9
3.8 Ongoing support and ensuring the sustainability of the EFDB ...................................................9
4. Structure and contents (discussed by BOG1)..............................................................................10
4.1 General aspects ..........................................................................................................................10
4.2 Information categories ...............................................................................................................10
4.3 Rational for distinction between mandatory and optional data fields........................................11
5. Functional design (discussed by BOG2) ......................................................................................15
5.1 Overview ...................................................................................................................................15
5.2 Database structure......................................................................................................................15
5.3 Technical issues .........................................................................................................................17
5.4 Methods of populating the database (inputs).............................................................................19
5.5 Methods of extracting information from the database (outputs)................................................19
5.6 Issues to be resolved by the Steering Group..............................................................................20
6. Recommendation to the Task Force Bureau on Update of Strategic Implementation Plan ...22
6.1 Update of work plan ..................................................................................................................22
6.2 EFDB Steering Group................................................................................................................23
Annex 1: Options for data collection and QA/QC procedures (presented in the discussion paperfor BOG3 in the meeting)..............................................................................................................25
Annex 2: List of paticipants ................................................................................................................30

Summary
The IPCC National Greenhouse Gas Inventories Programme (IPCC-NGGIP) held an expert meetingon Establishment of a Database on Greenhouse Gas Emission Factors in Paris, France, on 2-4 July
2001. The objectives of this meeting were:• Discuss the design of the database on GHG emission factors;•

Discuss/Identify the type of software to be used for the database;•

Discuss/Identify the most appropriate data collection and handling scheme to facilitate efficient
data collection and quality control of the emission factors of CO2, CH4, N2O, HFCs, PFCs, andSF6;•

Discuss the procedure and schedule for pilot-testing of the prototype database.

At this meeting, the participants reached agreement on most aspects as shown below but some aspects
were left for further consideration during later stages of the emission factors database (EFDB)
development.
1. Users of the EFDB must be able to trust the background information provided with thequantitative value they find. This means that the inclusion/exclusion of new data in/from thedatabase must be controlled. However usage of the EFDB information for compiling GHG
inventories will always be the full responsibility of the user.
2. Data in the EFDB can be provided by:•Parties to the United Nations Framework Convention on Climate Change (UNFCCC);•

Agencies and institutions;•Individual scientists or experts.

3. A number of operational constraints have been identified, which should be recognised when
designing the EFDB, especially in terms of the resources (mainly funding and personnel)
available both now and in the likely future. The EFDB should be designed to initially work at a
‘1st Phase’ level and be expandable to enable the functions required to meet long term
objectives when and if required.
4. Populating the system will not wait until users send in information but will be initiated withemission factors and other relevant parameters as available in:•

The Revised 1996 IPCC Guidelines for National Greenhouse Gas Inventories (the IPCC
Guidelines) and the IPCC report on Good Practice Guidance and Uncertainty Management
in National Greenhouse Gas Inventories (the Good Practice Report);•

National GHG inventory agencies1 , who are responsible for submission of their annual
national GHG inventories and report to the UNFCCC;•

Existing database of emission factors such as EDGAR, OLADE, USEPA. etc.

5. The required information categories and data fields were identified (see Table 1).
6. The EFDB should distinguish between mandatory and optional information to be contained in

1

Local data submitted from Parties not included in the Annex I to the UNFCCC (non-Annex I Parties) will bealso included if they are fully verified and in the appropriate form.

1the data fields. Some types of information are necessary for EFDB users (quality assessment,
assessment of applicability for other countries, etc), while a minimum burden to data providers
is essential to ensure data base population by countries and the scientific world.
7. The functional design elaborated 4 key areas that must be considered when writing the request
for proposals. These 4 areas are:•Database structure;•

Technical issues (hardware/software);•

Methods of populating the database (inputs);•

Methods of extracting information from the database (outputs).

8. Preferably, the EFDB should exist as both a web-based EFDB application and as a version thatcan be operated locally (on an individual’s PC). However, as resources may not support thedevelopment of two separate applications at this time, it was recommended that thedevelopment of the web-based program proceed first. The web application should be developedin a manner that will facilitate the development of a PC-based application, being fully awarethat it will be non-Annex I Parties that most need to draw on information in the EFDB. One
possible option may be to have a web-based submittal form for new data and a downloadable(plus CD-ROM version) database file of the EFDB. This means the web application should
support the downloading of the complete database (data only) directly to the user’s hard drive
so that the user can query it locally. Once the user has access to the data on a local drive, he/shecan execute large queries and avoid slow internet connections. This issue shall be further
considered by the EFDB Steering Group.
9. In order to ensure good management of the EFDB and to assure its usability, it is proposed thata Steering Group be established to be responsible for the EFDB management under thesupervision of the TFB.
10. The EFDB should be introduced widely to the world via UNFCCC sessions such as
SBSTA16 and COP8 in 2002 to increase awareness and contribution of data to/from mainly
non-Annex I Parties.

2

1.

INTRODUCTION

1.1

Background

The quality of national inventories of anthropogenic emissions by sources and removals by sinks ofgreenhouse gases not controlled by the Montreal Protocol (GHG inventories) depends substantially on
reliable emission factors and activity data. Although it is preferable to use emission factors that reflectnational circumstances, emission factor development is expensive, time consuming and necessitates awide degree of expertise. The Revised 1996 IPCC Guidelines for National Greenhouse Gas
Inventories (the IPCC Guidelines) and the recently published Good Practice Guidance andUncertainty Management in National Greenhouse Gas Inventories (the Good Practice Report)
provide default emission factors for the majority of source and sink categories. Some of these default
emission factors are region or country specific, but in general not all regions or countries are covered.
Sharing of research information would enable countries to use or develop emission factors that are
more reliable than the IPCC default emission factors without having to bear the associated researchcost. For this reason, many countries have indicated (e.g. in the Expert Group Meeting on National
Feedback on the Revised 1996 IPCC Guidelines for National Greenhouse Gas Inventories, Havana,Cuba, September 1998) that an easily accessible public database on GHG emission factors withsupporting scientific information would help improve the quality of GHG inventories in a costeffective way. A database on GHG emission factors with supporting scientific information would also
support the future review and update of the IPCC Guidelines under the IPCC National Greenhouse
Gas Inventories Programme (IPCC-NGGIP).
With this background, a project to establish a database on GHG emission factors was initiated with ascoping meeting held in New Delhi, India, on 24-25 July 2000. After this meeting, The Task Force
Bureau (TFB) on the IPCC-NGGIP discussed the future work plan for this project on development ofan emission factors database, at its 4th session, 8-9 December 2000, in Geneva. It requested theTechnical Support Unit (TSU) to prepare a strategic implementation plan (SIP) for theestablishment of an Emission Factors Database and submit it to TFB for consideration. In response tothis request, the TSU prepared the SIP based on the outcomes from the scoping meeting on this project
held in New Delhi, India, 24-25 July 2000. The SIP was endorsed by the TFB at its 5th session on 14
March 2001 in Geneva.

1.2

Objectives of the meeting

This first meeting in Paris was convened in line with the SIP to focus on:• the design of the database on GHG emission factors;•

the type of software to be used for the database;•the most appropriate data collection and handling scheme that will facilitate efficient datacollection and quality control of the emission factors of CO2, CH4, N2O, HFCs, PFCs, and SF6;•

the procedure and schedule for pilot-testing of the prototype database.

3

1.3

ParticipantsThis meeting was attended by 44 participants from 23 countries as well as from the Secretariat of theUnited Nations Framework Convention on Climate Change (UNFCCC), the International Energy Agency(IEA), the Organización Latinoamericana de Energía (OLADE), the Task Force Bureau of the IPCC
National Greenhouse Gas Inventories Programme (IPCC-NGGIP/TFB), and the Technical Support Unit of
the IPCC National Greenhouse Gas Inventories Programme (IPCC-NGGIP/TSU). The meeting was cochaired by Tinus Pulles from the Netherlands and Katarina Mareckova of the Slovak Republic.
The meeting was kindly hosted by the International Energy Agency (IEA).

42.

OVERVIEW

The meeting firstly reaffirmed the basic principles agreed at the scoping meeting in New Delhi.
•

The emission factors database (EFDB) will contain information and knowledge on emission
estimation methods for all relevant gases and sectors, including additional information needed foremission estimation. It will be fully referenced.

•

The EFDB will be an open system that will contain information to be provided by its users. It is
built on the principle of sharing knowledge and expertise within the user community to:−−

Make information on emission factors and related parameters available to all working
on the field;
Increase the quality of all greenhouse gas inventories.

Having reaffirmed these, the participants discussed two basic perspectives from which the EFDB canbe developed. Those are:
1. Providing the users with a “library” with all information that is available and the user makes
his/her choice on the basis of all material available;
2. Providing the users with an “authority”, advising the “best” value to the user.
The discussion did not result in taking either single option. Basically the “library” perspective was
supported, but it was also recognised that the EFDB should be designed to facilitate users’ selection of
the “best” values to them. In this context, it was agreed that users of the EFDB must be able to trust
the background information provided with the quantitative value they find. This means that theinclusion/exclusion of new data in/from the database must be controlled. However usage of the EFDB
information for compiling GHG inventories will always be the full responsibility of the user.
Then, the meeting split in three breakout groups (BOGs) as follows.
BOG1:

BOG2:

BOG3:

Contents and structure
Building on the results of the New Delhi meeting, the contents of the databaseneeds to be determined. This group focused on the emission inventory knowledge
that should be included into the EFDB.
Functional Design and Implementation
Implementation of the EFDB will need a series of consecutive steps. The first ofthese is the definition of the functional design of EFDB, in which the functional
structure of the database is identified and the input and output processes aredefined.
This group focused on the functional design of EFDB and hence concentrated on
the relational structure and input and output processes.
Management
Once EFDB is implemented, the system needs to be managed and maintained.
This group dealt with all relevant issues including definition of the tasks andaccess authorisation of different user groups (data users, data providers and systemmanagement).

The following chapters present the outcomes from each BOG discussion.

5

3.

MANAGEMENT (DISCUSSED BY BOG3)

3.1

General aspects

BOG 3 identified a number of operational constraints which should be recognised when designing the
EFDB, especially the resources (mainly funding and personnel) available both now and in the likely
future. The project has a guaranteed support during the initial start up period, this can be expected to
be followed by a period of growth in use and content (not necessarily at the same rate) during which
additional resources to operate and populate the EFDB will be needed. The design, while recognising
the long term desire for an open structure and an emphasis on information to assist non-Annex I
Parties to report national GHG inventories, should initially work within the guaranteed resources
available to the TSU. (Parties to the UNFCCC should be asked to contribute to the work.) Thisrequires the prioritisation of the most pressing needs of the EFDB during its early period and futurepriorities - ranked on the likelihood of obtaining additional resources. The design should consider both
database development/testing/population and the demands of future management systems. It should be
noted that any additional extra resources to populate the EFDB are likely to be from Annex I Parties –and thus reflect knowledge/technology in Annex I Parties – but that it will be non-Annex I Parties thatmost need to draw on information in the EFDB.
Consequently:
1. The EFDB should be designed to initially work at the ‘1st Phase’ level and be expandable to‘enable’ the functions required to meet long term objectives when and if required.2

2. Initially the EFDB should serve the most pressing user requirements. Prioritised in ‘immediateneed’ order, these are:•Priority 1: Inventory compilers (inventory agencies);•

Priority 2: IPCC (Future updates of the IPCC Guidelines);•

Priority 3: Inventory review teams, project developers involved in the Clean Development
Mechanism and Joint Implementation, corporations engaged in emissions trading, scientists,
the general public and NGO’s, and consultants.

3. The EFDB system access should start as open for all to ‘read’ but have restricted ‘entry’ towrite functions.
4. A support manual should be made available to EFDB users and contributors during the 1st
Phase (including prototype testing3) and 2nd Phase of EFDB development.
5. To assist with populating the EFDB and to broaden the type of data included ‘downloaders’should be encouraged to ‘contribute’.
These general points lead to specific requirements in database design, data quality control, database
operation/maintenance, required support systems, and so on.
2

The final objective is to develop an Option A type database starting with Option C (as outlined in the Annex tothis report).

3

Emission factor experts and national greenhouse gas inventory compilers should be testers of the EFDB
prototype.

6

3.2

Database design

Particular database design requirements arise from the need for data collection procedures and data
quality control. Initially, while resources are restricted solely to those of the TSU and contractors datafrom ‘accepted’ sources should be entered, these ‘1st Phase’ data sources are:
1. Default data for emission factors and other parameters from the IPCC Guidelines and the Good
Practice Report;
2. Emission factors and other parameters from national GHG inventory agencies, who areresponsible for submission of their annual national GHG inventories and report to the
UNFCCC;
3. Established databases (such as EDGAR, OLADE, USEPA etc).
In future, as and when resources allow, 2nd Phase data sources can be included, such as:
1. Academics, literature or other peer reviewed information;
2. Experts identified by Parties or the EFDB Steering Group.
The design must allow bulk entry of information immediately and ad-hoc data entry at a later date.
In order to minimise the time and resources to input data (and encourage its use) the EFDB should
distinguish between mandatory and optional fields.

3.3

Data quality control

The data quality control should reflect the nature of the data being entered on the EFDB. There are
two development phases to ensure data quality control:•

1st Phase data: These require the lowest possible review/screening consistent with users being
able to judge the applicability of data for their own use, nevertheless the following generic data
fields should be mandatory:−−

Administrative data identifying the source of the information (Country, Agency, etc.);
Technical information, including a reference, fact sheet (executive summary to be in
English if the reference document is not available in English);− Usage/Review information (to enable a user to judge applicability).
And as optional fields:− Additional information fields may also be included.
•

2nd Phase data: These will need more scrutiny via Expert/Evaluation Committee(s) and ‘smart
software’ (to check for completeness) depending on its source – but should always be at thelowest level practicable. Mandatory entry fields to be filled will need to be more extensive:−−−

Place of origin;
Source of data: Annex I Parties (National Inventory Report), Party nominated experts,scientific research, etc;
Technical references:• Reference – fact sheet – executive summary – in English• Date tag• Attached scientific report, research papers (published), link to informationsites (future) – link to document submitted to the TSU;

7

−
−

Use indicators (National Inventory Use);
Information on the review of data (how it was developed and reviewed) either from• emission factor contributorsor• the Expert/Evaluation Committee(s).
And as optional fields:− Additional information, i.e. suggestions as to how other parties can use the data–applicability, associated references and as resources allow ‘hot links’ (when feasible).

3.4

Database operation/maintenance

The TSU should host the EFDB during the development, testing and period of early use but as usage
increases additional support will be required. The EFDB design must allow for some sharing ofoperation, data entry and maintenance, etc.
The database should be publicly available but information relating to the supplier of information
should be restricted to the EFDB manager in order to limit the cost of responding to enquiries. The
EFDB Steering Group (referred to later in section 3.8) should decide how and in what detail to
respond to enquiries. The EFDB may have to have a frequently asked questions (FAQ) facility.
A separate expert network, with an electronic discussion group (EDG) developed to answer enquiries,
will build a self help group and encourage the population of and users’ intimacy with the EFDB.
System manual and other supporting documentation should be prepared.
• Supporting Manual with instruction on using the EFDB and its associate e-forms for the 1st
and 2nd phase data entry. (N.B. this should be a component of the database contract).

3.5

Supporting systems to be introduced as resource and time allow

Comments/feedback should be collected and fed to the EDG – the EFDB design should enable a ‘flag’system to indicate where information on an entry is the subject of discussion on the EDG.
Expert/Evaluation Committee(s) will manage the input of 2nd phase data to the EFDB.
A network of users to encourage broadening of the EFDB coverage should be identified and created.

3.6

Distribution of the EFDB

To ease document control the master version should be web-based with date marked CD copies
available on request. Maintenance issues relating to update and database manager should beconsidered by the EFDB Steering Group which is referred to later in section 3.8.

8

3.7

Language

English should be used in all mandatory fields but multilingual capability is desirable and original
language of reference document can be submitted with an English executive summary.

3.8

Ongoing support and ensuring the sustainability of the EFDBThis will require active advertising and promotion of EFDB activity. Since the project will develop in timeand consequently the needs of the EFDB will also change, it is recommended that a Steering Group be set
up to assist the TSU with the management of the EFDB.
It was also suggested that the EFDB should be introduced widely to the world via UNFCCC sessions suchas SBSTA16 and COP8 in 2002 to increase awareness and contribution of data to/from mainly non-Annex I
Parties.

9

4.

STRUCTURE AND CONTENTS (DISCUSSED BY BOG1)

4.1

General aspects

BOG1 agreed upon the following principles in general aspects.
• Focus on 6 direct GHGs (CO2, CH4, N2O, HFCs, PFCs4, SF6), but information may be given on
other gases (indirect GHGs) so that the EFDB can be expanded in the future;•

Report on not only emission factors but also other parameters to calculate GHG emissions andremovals5;•

Use the IPCC source/sink categories6, as detailed as possible;•

Use common format for all sectors, if possible (to enable easy querying across sectors);•

Report in common units whenever possible, besides original units;•

Refer to “Tiers” or estimation equations, though not mandatorily, where the emission factors orother parameters in question should be used (Reference to “Tiers” is optional while reference toemission estimation equations is recommended.);•Distinguish between mandatory and optional data fields;•

Not include detailed descriptions of complex mathematical models. However, if some models areused to calculate emissions then resulting emission factors and other parameters can be included
with precise reference to the models.

4.2

Information categories

BOG1 identified a variety of types of information that should be contained in the submissions to the
EFDB; in accordance with the recommendation by BOG3 on the requirements for data quality control
especially in 1st Phase (see page 7, section 3.3) these can be structured as follows
1. Administrative information•

Data provider and contact information.

2. Technical information•

Value, descriptive name, unit, etc. of emission factors or other parameters;•

Reference to the IPCC source/sink category;•

Main influencing factor(s) and additional influencing factor(s);−4Influencing factors should be split into main and additional factor(s) in view of thelevel of importance. For example, in the case of N2O emission factors from “Roadtransport”, main influencing factors are fuel type, control technology (e.g. catalyst

More specifically, each of the hydrofluorocarbons (HFCs) and perfluorocarbons (PFCs) mentioned in Table 1of the Common Reporting Format of the UNFCCC (see UNFCCC document FCCC/CP/1999/7).
There are two types of parameters to be included in the EFDB, i.e. parameters to calculate emission factors and5those to calculate actual emissions.
The IPCC source/sink categories are presented in the IPCC Guidelines, Vol.1, Reporting Instructions.

6

10

•

type), etc 7 , and additional influencing factors are shares of cold starts/urban/
highway/rural/maintenance level, etc.
Reference to the method used (basic equation, IPCC Tier, summary of complex method);•

Reference to written material;•

Data quality (uncertainty estimate and other quality aspects8).

3. Usage/Review information•

Information on present application and potential applicability.

In Table 1, the required information categories and data fields are listed and described.

4.3

Rational for distinction between mandatory and optional data fields

BOG1 agreed, as did BOG3 (see page 7, section 3.2), that the EFDB should distinguish between
mandatory and optional information. The rational for this distinction is that some types are critical for
usage by the identified user categories for the EFDB (quality assessment, assessment of applicability
for other countries, etc), while a minimum burden to data providers is essential to encourage data base
population by countries and the scientific world.
An exception to this will be allowed for existing reference data sets, such as default data for emission
factors and other parameters from the IPCC Guidelines and the Good Practice Report,
UNECE/CORINAIR default data, USEPA AP42 default data, EDGAR/GEIA emission factors and
OLADE emission factors9. This is to allow data comparison by the users to reference data sets.
Besides a formal screening of the presence of the mandatory fields, a basic screening of the contents of
information supplied to the EFDB will be part of the acceptance procedure. In the future more formal
quality aspects will be included in this procedure.

7

Some participants proposed that a certain factor, among other main influencing factors, should be further

emphasised for each IPCC source/sink category (e.g. fuel type for Energy Sector).
8

Data quality ratings developed for other data sets in existing databases can be quoted here but no new quality
rating scheme will be developed especially for the EFDB.

9

These data are supposed to be entered into the EFDB in the “1st Phase” (see page 6).

11

TABLE1. REQUIRED INFORMATION CATEGORIES AND DATA FIELDS
Required data fields
1. Administrative information
Person/agency that submitted the data•
- Name of the person/agency- Country- Contact information

2. Technical information
Gas•

Mandatoryor Optional

NOTE

Mandatory

Direct contact information such as phone numbers and e-mailaddresses of data providers should be submitted to the databasemanager, but may not be shown openly to the users. This isbecause it may be a deterrent for data providers to contribute theirdata if they do not have time and resources to handle direct
inquiries.

Mandatory

CO2, CH4, N2O, SF6 and each of the HFCs and PFCs mentioned in Table
1 of the Common Reporting Format of the UNFCCC.

Follow the IPCC source/sink categories.
Category definitions listed in the IPCC Guidelines, Vol.1,
Reporting Instructions, should be used. If no specific category
applies, sector “other” should be used.
IPCC worksheet numbers presented in the IPCC Guidelines,
Vol.2, Workbook, should be used.
e.g. fuel type, technology type, livestock subtypes (see page 14,
Box1 “Example for Common Sectoral Approach”.)Some participants proposed that a certain factor for each IPCC
source/sink category should be further emphasised among others(e.g. fuel type for Energy Sector).
e.g. load factors, capacity, maintenance level, feed composition(see page 14, Box1 “Example for Common Sectoral Approach”.)
If applicable, also the value of these factors should be specified
Maybe some guidance on exact terminology will be necessary to
be able to perform correct queries.
Average•

IPCC source/sink category or activity definition

Mandatory•

IPCC worksheet number if applicable

Optional•

Main influencing factor(s)Mandatory•

Additional influencing factor(s)Optional•

Descriptive name of emission factors or other parameters

Mandatory•••

Value of the parameter in original units
Original unit of parameter
Value of the parameter in common units

Mandatory
Mandatory
Optional••

Common unit of parameter
The equation used for estimating the emission (Tier)

Optional
Optional

12

If possible, common units should also be submitted together withthe conversion factors used.
Tier – optional
Equations – recommended•

Source of data (Use indicator)

Mandatory•

Technical reference- Full Reference- Language- Abstract in English
Upper and lower boundaries (confidence limits) at the 95%
confidence interval or uncertainty

Mandatory
Mandatory
Optional
Mandatory••

Data quality- Calculated, expert judgement, modelled or based on existing Mandatory
systems USEPA, CORINAIR- Give info on shape of distribution (normal, log normal, uniform, Optional
triangle, …)

e.g. scientific literature, official national inventory reports (NIRs),
other country inventory studies, other, …

Include text box to explain when range or uncertainty is not
given/available or give expert judgement on order of magnitude of
uncertainty. The units of the range should be specified.
This will be not mandatory for existing reference data sets to beentered during “1st Phase”, such as default data from the IPCC
Guidelines and the Good Practice Report, UNECE/CORINAIR
default data, USEPA AP42 default data, EDGAR/GEIA emission
factors and OLADE emission factors.
Data quality ratings developed for other data sets in existing
databases can be quoted here but no new quality rating scheme
will be developed especially for the EFDB.

•

Reference of data quality if different from reference of emission Optional
factors or other parameters
Optional
Other information relevant to the determination of the quality•
3. Usage/Review information
Mandatory
Type of emission factors
•
•

•
•
•
•
•

Information on the review of the data
- Measured data
- Measurement techniques- Amount and frequency of measurements- Date of measurements- Modelled data (to be defined)Year in which the data are applicable
Country/region where the data applicable
Possible applicability
Comments from the data provider
Comments from “others”

Mandatory

Optional
Optional
Optional
Optional
Optional

13

Measured, Modelled, Compiled or “Implied” (see footnote 10 on
page 17) from a reported set, Adjusted (to reflect a specificcountry)
Minimum information for measured data could include:measurement standard, periodicity of measurement, external
quality control performed.

BOX 1: EXAMPLE FOR COMMON SECTORAL APPROACH<ENERGY Sector>
IPCC source/sink category: “lAl Energy industries”…“1Ala(i)-Public Electricity Generation”
Main influencing factors: fuel type - combustion technology (e.g. boiler, FBC, capacity) - control
technology (e.g. FOD)
Additional influencing factors: load factor; maintenance level
IPCC source/sink category: “1A3 Transport”…“1A3b(i) Cars”
Main influencing factors: fuel type - control technology (e.g. catalyst type)
Additional influencing factors: shares of cold starts/urban/highway/rural/maintenance level
IPCC source/sink category: “1A4 Other Sectors”…“lA4b-Residential”
Main influencing factors: fuel type - combustion type (e.g. central beating, fire place, cooking)
Additional influencing factors: load factor, moisture content of biofuel; maintenance level
IPCC source/sink category: “lB1a(i) Coal Mining, Underground Mines”
Main influencing factors: production technology
Additional influencing factors: rnethane recovery<INDUSTRIAL PROCESSES Sector>
IPCC source/sink category: “2B Chernical Industry”…“2B2 Nitric Acid Production”
Main influencing factors: production technology (e.g. old methodology/NSCR/...)
Additional influencing factors: maintenance level; average effectiveness of control technology<AGRICULTURE Sector>
IPCC source/sink category: “4A Enteric Fermentation”…“4A1a Dairy Cattle”
Main influencing factors: animal subtypes (e.g. young animals/males/females)
Additional influencing factors: feed composition, climate<LAND-USE CHANGE AND FORESTRY Sector>
IPCC source/sink category: “5A Changes in Forest and Other Woody Biomass Stocks”…“5A1
Tropical Forests”
Main influencing factors: tree species
Additional influencing factors: country<WASTE Sector>
IPCC source/sink category: “6B Wastewater Handling”…“6B2 Domestic and Commercial
Wastewater”
Main influencing factors: Wastewater characteristics – Handling systems
Additional influencing factors: temperature

14

5.

FUNCTIONAL DESIGN (DISCUSSED BY BOG2)

5.1

Overview

BOG2 addressed the design of the EFDB and the tools or applications which will be used to access theinformation in this database. This section addresses the four main areas that must be considered whenwriting the specification for the database design and highlights some issues and problems which need
to be resolved. These four areas are:
1. Database Structure;
2. Technical Issues (hardware/software);
3. Methods of populating the database (inputs);
4. Methods of extracting information from the database (outputs).

5.2

Database structure

The database structure is presented in Figure 1. It provides a high level overview of the main
informational areas which define an emission factor. These areas will translate into related tables inthe EFDB. This diagram is not exhaustive; it is a starting point for creating a detailed data map inwhich the individual tables, fields, and relationships are outlined.
The main functional areas on this diagram are:a) Gases; b) Reference/Quality; c) IPCC Source/Sink Category; and d) Unit of Measurement.
5.2.1 Gas Table
As agreed in the scoping meeting on this project held in New Delhi in 2000 and reaffirmed by BOG1,
the focus of the EFDB is GHGs, and as such it will only contain emission factors and other parameters
for the following direct GHGs: CO2, N2O, CH4, SF6, PFCs, and HFCs. If necessary, additional GHGs
could easily be added to the database without increasing the number of fields in the database oraltering the database structure. Other gas attributes could be readily stored in the gas table, forexample, Global Warming Potential (GWP), full gas name, molecular weight, etc.
5.2.2 Reference/Quality Table
This table is very important to the proper use of the EFDB because it will contain the information thatwill enable the user to evaluate the quality of an emission factor or other parameter. It will not containa new quality rating developed solely for the EFDB, but will store existing quality ratings developed
for other data sets (for example, for USEPA AP42 or UNECE/CORINAIR). It will also contain text
descriptions summarising how the factor was derived, an abstract of any published references,complete technical references, complete contact information (name, organisation, etc.), a descriptionof measurement methods, the equation used for estimating the emission (Tier), and key dates related tothe data submittal and factor creation. The table will also store the upper and lower boundaries for the
95% confidence interval for the emission factor or other parameter.

15

FIGURE 1. DATABASE STRUCTURE

16

5.2.3 IPCC Source/Sink Category Table
The activity information related to the emission factor or other parameter will be defined by the IPCC
source/sink category in conjunction with key additional descriptive factors. This information includes
technology-specific data, geographic-specific information (climate, latitude/longitude, altitude, etc.)
and fuel data. In those cases, in which these additional data are not applicable these fields can remainblank. BOG1 has given some examples of descriptive factors that should be stored for eachsource/sink category (see page 14, Box1 “Example for Common Sectoral Approach”). Additionally,
the source/sink category table can (but does not have to) map the IPCC source/sink category to thecategory codes developed in other systems (SNAP, NFR). The design of this table is crucial to thequerying capabilities of the database and careful thought should be given to the individual fields.
5.2.4 Unit of Measurement
The unit of measurement table(s) will contain all standard units and supply conversion factors for thevarious units. Other factors which need to be considered here include: flue gas concentration, andaggregation level (real vs. implied10). We should consider moving these latter parameters into the data
quality reference table.

5.3

Technical issues

The technical issues are outlined in Figure 2.
In writing the specifications for the software we need to make sure this database and its applications
are readily accessible to most users. To this end, the EFDB should require a minimum of system
resources (e.g. Windows 95 compatible, Office 95 Compatible, Pentium I co-processor, 32 megabytes
RAM). It should be developed in a widely accepted programming language and have the potential tosupport multiple (linguistic) languages.
BOG2 preferred that the EFDB exist as both a web-based EFDB application and as a version that canbe operated locally (on the individual’s PC). However, as resources may not support the developmentof two separate applications at this time, BOG2 recommends that the development of the web-based
program proceed first.11 The web application should be developed in a manner that will facilitate thedevelopment of a PC-based application.
Prior to the development of a PC-based application, the web application should support the
downloading of all the EFDB (data only) directly to the user’s hard drive so that the user can query it
locally. Once the user has access to the data on a local drive, he/she can execute large queries and

10

The scoping meeting on this project held in New Delhi in 2000 noted “Implied emission factors, as defined in
the UNFCCC Common Reporting Format, in most cases are time-dependent and weighted averages of theunderlying emission factors used in the calculation of GHG emissions. They could be included as a second
priority with a clear indication that they should not be used for inventory calculations directly, but may serve as
an order of magnitude check.”11

In the last plenary session, however, some participants stressed the significant advantages especially to nonAnnex I Parties that would be provided by the PC-based database. One possible option may be to have a webbased submittal form for new data and a downloadable (plus CD-ROM version) database file of the EFDB. Thisissue shall be further considered by the EFDB Steering Group.

17

avoid slow internet connections. (Downloading files raises the issue of version management. See theend of this section for a discussion of this issue.)Protection and security must also be considered and will be the joint responsibility of the organisation
hosting the database on its server and the database designer.

FIGURE 2. TECHNICAL ISSUESFIGURE 3. METHODS OF POPULATING THE DATABASE

18

5.4

Methods of populating the database (inputs)

The methods of populating the database are outlined in Figure 3.
5.4.1 Bulk import
To make the EFDB functional as soon as possible, BOG2 recommends that existing emission factor
databases be imported into the EFDB as BOG3 also suggested (see page 7, section 3.2). In order to do
this, a common import format needs to be agreed upon by the data providers and the databasedevelopers. Possible common formats include Excel, ascii-text files, dbase and Access files. This bulk
import process should occur early into the development process to allow testing and debugging of theapplication. During this phase a data dictionary needs to be developed so that each database can bemapped into the EFDB. Although some of the databases use IPCC definitions, converting each ofthese databases to the EFDB format may require significant resources. It is unclear as to who will
have this responsibility (TSU or the IT contractor). Synchronisation of the EFDB with future versionsof existing databases such as EDGAR, OLADE also needs to be addressed.
5.4.2 Single import
A web form for uploading individual emission factors into the EFDB will also be needed. This formshould contain a series of textboxes and drop-down boxes to readily obtain the information from theuser. Quality checks for mandatory fields (see pages 12 to 13, Table 1) should be built into this form.
Additionally, the TSU will do an initial “sanity check” of all factors submitted. This input process
should allow revisions to existing factors, additions of new factors, and deletions of existing factors.
This is a critical input process since it is during this stage that the emission factors and otherparameters that are more relevant to developing countries are most likely to be added.
5.4.3 “Mini-batch” import
In addition to bulk and single import processes, we need to provide a middle ground for thoseemission factor developers who wish to submit a small batch of emission factor records (perhaps on
the order of 10 or 20 individual records). For example, the user could fill out an Excel spreadsheet
template or Access database template and email or ftp the submission to a central administrator.
Again, we need to consider when and how these submittals are included in the master database andwho reviews them.

5.5

Methods of extracting information from the database (outputs)

The methods of extracting information from the database are outlined in Figure 4.
An important part of the database tool will be making the information available to users. To this end,
BOG2 recommends that the users be able to query the database on the following fields: Source
Category (to the technology level), gas, region, geographic conditions, fuel type and unit type. Query
screens should be refined during the development process. The user should be able to make theirselections by from one or more of these descriptive categories by using dropdown boxes. The user
should be able to sort and filter the output. The results of queries could be presented as tables, graphs,
and reports. The EFDB web tool should be capable of creating ad-hoc reports from queries and preformatted fact sheets on specific emission factors or other parameters. These reports should beaccessible in different formats (e.g. Excel, adobe (.pdf), and Word (.doc)).

19

Finally, the EFDB application should be capable of exporting the database tables as ascii text files,
Excel sheets, and in other common database formats. The user should also be able to request a copy ofthe data on CD-ROM.
BOG2 also discussed creating management reports that are created off-line and will summarisechanges to the EFDB since the preceding year or last official version. BOG2 members also requested
that a overview report be created summarising key attributes of the EFDB (e.g. Number of factors byregion, category etc.)
FIGURE 4. METHODS OFDATABASE

5.6

EXTRACTING

INFORMATION FROM

THE

Issues to be resolved by the Steering Group

There are a some important issues related to data import and export that need resolution by the EFDB
Steering Group proposed by BOG3. These issues include:
1. Resolving supervisory responsibilities - BOG2 proposed that an editorial board review allchanges and additions to the EFDB. An email message would be generated and sent to eachmember of the board upon the submittal of any new data. Until final acceptance into the EFDB,
the record could be flagged as “pending” or be held in a separate database until reviewed andaccepted. However, maintaining such an editorial board is an additional administrative burden.
(Ultimately, the users of the EFDB are responsible for the consequences of their use of any
factor in the EFDB when compiling their GHG inventory and should review all supporting
reference documentation carefully.)
2. Continuous updating vs. batch updates to the database – BOG2 discussed whether eachindividual submittal should be automatically be incorporated into the “live” publicly accessible
database or whether these submittals should only be incorporated once or twice each year in abatch upload into the master. BOG2 did not decide which method was better. It was noted thatscientists would prefer continuous updates since they are in search of the most recent data at all
times. Inventory compilers may prefer less frequent updates, as they only need to compile their20

inventories once each year and would not want to revise their data each time a new factor
appeared.
3. Version management is a key issue that the Steering Group needs to resolve and is related tothe issues outlined in #1 and #2 above. If users can download the data at any time to their local
PCs, should they be downloading the most recent data including all recently submittedchanges? When users query the on-line database, will they see all recently submitted additions
and revisions or only the last published version of the database? What of the “mini-batch”
additions? When will those appear in the database? When requests for CD-ROMS are made,will these CDs contain the most recent data or data that is updated only in six monthincrements (or some other interval)? Should all versions of the database at any given time be
identical? The contractor chosen to develop the EFDB should help resolve these issues
providing input on cost and ease of different version management systems.

21

6. RECOMMENDATION TO THE TASK FORCE BUREAU ON UPDATE OF STRATEGIC
IMPLEMENTATION PLAN
6.1

Update of work plan

Following the discussion at the meeting, it is suggested that the TFB update the work plan in the SIP
as follows.
Preparation of the call for tender to produce the EFDB and set up of the Steering Group[at TFB 6, 9 August 2001]
The TSU and the Co-Chairs of the EFDB Project will draft the call for tender to produce the databasebuilding upon the conclusions of this meeting by the end of July. The call for tender will be subject toendorsement by the Task Force Bureau (TFB) at its 6th session to be held on 9th August 2001 in
Geneva, Switzerland.
Also, the members and responsibilities of the EFDB Steering Group will be recommended to the TFB
for their endorsement at the same session.
Call for tender, selection of the IT experts (software developers)[By the end of August]
After endorsement by the TFB, the TSU will issue a call for tender to some candidate softwaredevelopers with a view to selection of the most appropriate IT experts by the end of August.
Development of a prototype database (Detailed design and Programming)[September – December 2001]
Selected IT experts will further develop the database structure and the input and output processes as
decided upon in the functional design. This process will be supervised by the TSU in consultation with
the Co-Chairs of the EFDB Project and the TFB members. Also it is desired that a group representing
the users judge the final detailed designs of input and output windows and forms.
Having finalised the detailed design of the database, the IT experts will implement it in applications
and a set of working web pages. During this process, user’s manual and relevant documents have to be
developed. Furthermore, the default data presented in the IPCC Guidelines and the Good Practice
Report will be put into the prototype database during this phase.
The prototype database, together with user’s manual and relevant documents, is expected to be readyby 14 December 2001.
Pilot testing of the prototype database[January – March 2002]
The prototype database will be made available to expert reviews including all participants in thismeeting for pilot testing between late January and late March 2002.
(All participants in this meeting are invited to take part in the pilot testing.)
The reviewers will be requested to submit their comments to the TSU in a timely manner. The TSU
will prepare a summary table of the comments for consideration by the Second Expert Meeting.

22

Second Expert Meeting [small-scale, mid April 2002]
For continuity, this meeting will involve as far as possible participants from the first expert meeting.
Participants are expected to:(i) Further discuss technical aspects to improve user-friendliness of the database taking into
consideration the comments from reviewers;(ii) Further elaborate the most appropriate data collection and QA/QC procedures building upon the
conclusions of this meeting.
(iii) Determine the procedures and schedule for data populating.
Demonstration of the prototype database at SBSTA16 [June 2002]
The TSU will hold a special side event to demonstrate the EFDB (prototype) at SBSTA16 in June
2002, with a view to enhancing the public awareness of this project and the EFDB.
Finalisation of the EFDB construction[May – October 2002]
Any bugs or other shortcomings of the prototype database and (web) application identified by the pilot
testing will need to be promptly repaired. The user group that judged the detailed design is also
mandated to check the bug repairing process.
TFB will discuss the outcomes of the Second Expert Meeting, probably in May or June 2002, with the
Co-Chairs of the EFDB Project. The TSU will implement the TFB decision on the refinement of thedatabase, with the IT experts. The TSU will also implement the activities to collect and input moredata. Data collection and input into the database at this stage will be implemented according to theprocedures and schedule agreed upon by the Second Expert Meeting.
The EFDB will come into full operation by the end of October 2002.
Demonstration of the complete EFDB at COP8 [November 2002]
The TSU will hold a special side event at COP8 to make an announcement of establishment of the
EFDB and to demonstrate how to utilise it.

6.2

EFDB Steering GroupIn order to ensure good management of the EFDB and to assure its usability, it is proposed that a
Steering Group is established to take on the following responsibilities under the supervision of the
TFB:• Prepare decisions on all open issues in time for implementing in the first version of EFDB
planned for end of 2002;•

Follow and assess progress in executing the Strategic Implementation Plan for the Establishmentof an Emission Factors Database (SIP);•

Mediate and propose solutions for any problems or decisions that might arise during
implementation, population and testing of EFDB;•

To steer and arrange the further development of EFDB once the first release has been published,
and deal with the long term issues including establishment of “editorial board”, modality of
updating, and version management, as proposed by BOG2;

23

•

Prepare a solution for long term ownership and hosting of EFDB for consideration by the Task
Force Bureau on the IPCC National Greenhouse Gas Inventories Programme;•

Harmonisation with other activities such as UNECE Task Force on Emission Inventory andProjection (TFEIP).

24

ANNEX 1:
OPTIONS FOR DATA COLLECTION AND QA/QC PROCEDURES (PRESENTED IN THE
DISCUSSION PAPER FOR BOG3 IN THE MEETING)
In the discussion paper for BOG3 in the meeting, 3 options for data collection and QA/QC proceduresare presented for consideration. These options were developed taking into consideration the outcomesof the New Delhi scoping meeting. These were presented, among many other possible options, just to
facilitate discussion in this meeting.
TABLE: SUMMARY OF THE OPTIONS PRESENTED IN THIS SECTION
Option A

Option B
Only accredited experts

Option C
Only
accreditedorganisations
By regular expert meetings By data providers themselvesorganised by source categoryHighquality will
be QA/QC can be achieved inconfirmed for all of the data an efficient manner, which
included in the database. will reduce the workload ofUsers may be able to fully the database host.
rely on the data quality.

Data Providers

AnyoneQA/QC

By an editorial board

Merit

Wide collection of data will
be expected.
Users may be able to findmore suitable data to theircircumstances among thewide range of information.
- Data of not so high quality are included,
though minimum quality
requirement will be ensured.
- The workload of thedatabase host will be heavy.

DemeritCost implications-

Need to maintain the editorial board
Need to support heavy
workload of the database host25

Variety of the data included in the databasewould be reduced.
The workload of thedatabase host will beheavy.
Organising the regularexpert meetings will bequite a burden.
Need to convene the expert meetings on aregular basis
Need to support heavy workload of the databasehost

It is difficult to ensure
consistency among data
providers in terms ofstrictness of data quality
checksThe data of so highquality are included,
though minimum quality
requirement will beensured.
Need to maintain thegood network of the data
providers.
Needtosupportworkload of the databasehostOption A: Wider data collection with minimum quality check by an editorial board

Principles
This option is to pursue as wide inclusion of data as possible. Key elements of this option are as
follows.

Data providers
The option 1) presented in the section 2.3 would be taken, i.e. no restriction on the qualification to
propose data for inclusion into the database. Anyone can make a proposal.

QA/QC procedures
The concept of the options 1) and 2) presented in the section 2.3 should be taken, i.e .to include datafrom all possible sources but only those with no or little reference information. To ensure theminimum quality, an editorial board consisting of inventory experts will be organised. The editorial
board will judge the data proposed to be included against the criteria with the assistance of thedatabase host (or the TSU).

Criteria for inclusion of data
All data will be included if the following conditions are met at least:a) They are not included in the database yetb) Their origin is traceable and knownc) They are accompanied with at least the following attributes:−−−

the gasthe IPCC source sector the emission factor applies to
the key influencing factors (e.g. geographical area where the data is applicable)

Procedures
Bulk upload
In the early stages of populating the database, it is likely that information of existing collections ofemission factors are offered for inclusion. Such collections will be accepted by EFDB for inclusion if
each factor complies with the condition c) above. In this case the origin will refer to the originalemission factor collection.

Individual candidate data
1. EFDB candidate data are proposed (electronically) to the database host.
2. The host sends the candidate data for review to at least two members of the editorial board withexpertise in the relevant sector.
3. If both members agree that the above criteria are met, the factor is accepted. If both agree that thecriteria are not met, the factor is refused. If the two members disagree, the factor is sent out to allmembers of the editorial board and acceptance is by “a majority of votes”.

Key question for this option!"How many experts and through what procedures should the editorial board be organised?
TOR of the editorial board may have to be devised.

26

Option B: Intensive quality assurance and quality control by regular expert meetings

Principles
This option is to ensure all the data included in the database are of high quality. It allows only the data
selected carefully to be included. Key elements of this option are as follows.

Data providers
The option 2) presented in the section 2.2 would be taken, i.e. only the partners specified throughan agreed procedure could be allowed to propose data in a standard format, for inclusion into
the database.

QA/QC procedures
The concept of the option 3) presented in the section 2.3 would be taken, i.e. to include only the data
carefully screened through regular expert meetings, organised by source category. This might
require significant financial and institutional resources that are not currently available.

Criteria for inclusion of data
Data to be included in the database have to meet the following conditions at least:a) They are not included in the database yetb) Their origin is traceable and knownc) They are accompanied with at least the following attributes:
−
−
−
−
−

the gasthe IPCC source sector the emission factor applies to
the key influencing factors (e.g. geographical area where the data is applicable)
uncertainty data
reference informationd) The high quality of the data (or the reliability of the reference) should be strictly confirmed
through careful examination by the regular expert meetings.
More detailed criteria must be developed by the regular expert meeting at its first session.

Procedures
1. EFDB candidate data are proposed (electronically) to the database host.
2. The host prepares and submits the documents containing information on the candidate emission
factors to the regular expert meetings for review.
3. The regular expert meetings organised by source category undertake careful examination of thecandidate data and make decisions whether to accept them or not.

Key questions for this option!"How many experts and how often should the regular expert meetings be organised? TORof the regular expert meetings may have to be devised.
!"How can we make the detailed criteria, in particular d) above, practical and adequate?
!"How should we treat the default values in the IPCC Guidelines and in the Good Practice
Report? Some of them may fail to meet the rigorous criteria suggested by this option.
!"How should we treat information of existing data collections? Should we allow the bulk
input, or apply the same strict criteria as is the case with the individual candidate data?

27

Option C: Decentralised autonomous quality assurance and quality control by a limited number ofdata providers

Principles
This option is to seek an efficient way to undertake QA/QC of the data for inclusion into the database.
Key elements of this option are as follows.

Data providers
The option 2) presented in the section 2.2 would be taken, i.e. only the partners specified throughan agreed procedure could be allowed to propose data in a standard format, for inclusion into
the database. Furthermore, the data providers are expected to be rather reliable organisations in thiscase. Governments would be one of the most probable candidates.

QA/QC procedures
The concept of the option 4) presented in the section 2.3 would be taken, i.e. to include only the datasubmitted through a limited number of data providers (e.g. governments), who would pre-screen
the data according to the criteria. QA/QC is to be done only by the accredited data providers
themselves in this option.

Criteria for inclusion of data
Data to be included in the database have to meet the following conditions at least:a) They are not included in the database yetb) Their origin is traceable and knownc) They are accompanied with at least the following attributes:
−
−
−
−
−

the gasthe IPCC source sector the emission factor applies to
the key influencing factors (e.g. geographical area where the data is applicable)
uncertainty data
reference informationd) The quality of the data (or the reliability of the reference) should be checked by theaccredited data providers themselves.
More detailed criteria must be developed to ensure consistency among different data providers.

Procedures
1. The data providers check the quality of EFDB candidate data according to the agreed criteria before
submission to the database host.
2. EFDB candidate data that have gone through the quality check by the data providers are proposed(electronically) to the database host.
3. The database host accepts all of the proposed data.

Key questions for this option!"How should we select the data providers?
!"How should we develop the detailed criteria to be commonly used by the data providers?

28

!"How should we treat the default values in the IPCC Guidelines and in the Good Practice
Report? Some of them may fail to meet the rigorous criteria suggested by this option.
!"How should we treat information of existing data collections? Should we allow the bulk
input, or apply the same strict criteria as is the case with the individual candidate data?

29

ANNEX 2: LIST OF PARTICIPANTS
IPCC Expert Meeting:
Establishment of a Database on Greenhouse Gas Emission Factors
International Energy Agency (IEA)
Paris, France
2 - 4 July, 2001

ARMENIAMr Martiros TSARUKYAN
Ministry of Nature Protection
375002, Moskovian St. 35,
YerevanTel: (37 41) 53 49 82
Fax: (37 41) 151 959
Email: martiros@nature.am

CHINA
Mr Yun LI
Energy Research InstituteB-1407, Guohong Hotel
A-11, Muxidi Beili Xicheng District
Beijing 100038
Tel: (86 10) 63908457
Fax: (86 10) 63908457
Email: liyun71@263.net

BELGIUM
Dr Pascal BOECKX
Ghent University
Coupure 653
B-9000 Gent
Belgium
Tel: (32 9) 264 6000
Fax: (32 9) 264 62 30
Email: pascal.boeckx@rug.ac.be

CZECH REPUBLICDr Pavel FOTT
Czech Hydrometeorological institute
Na Sabatce 17
CZ-143 06 Prague 4
Tel: (420 2) 4403-2456
Fax: (420 2) 4403-2468
Email: fott@chmi.cz

BRAZIL
Ms Branca AMERICANO
Ministry of Science and Technology of Brazil
Rue Real Grandeza, 219
Bloco "O" sala 208 - CEMEE
CEP-22281-030 Rio de Janeiro - RJ
Tel: (55 21) 5284377
Fax: (55 21) 5285858
Email: bamericano@mct.gov.br

ESTONIADr Ants MARTINS
Estonian Energy Research Institute
Paldiski Road 1
10137
TallinTel: (372) 6621664
Fax: (372) 6613655
Email: martins@eeri.ee

CANADA
Ms Chia HA
Environment Canada
9th Floor, PVM
351 St. Joseph Blvd.,
Hull, Quebec K1A 0H3
Tel: (1 819) 997 7511
Fax: (1 819) 953 9542
Email: Chia.Ha@ec.gc.ca

FINLAND
Ms Kristina SAARINEN
Finnish Environment Institute
P.O.Box 140
FIN - 00251 Helsinki
Tel: (358 9) 40300456
Fax: (358 9) 40300490
Email: Kristina.Saarinen@vyh.fi

30

FRANCEMr Jean-Pierre CHANGCITEPA
10 rue de Faubourg Poissonniere
75010 PARIS France
Tel: (33 1) 44 83 68 83.
Fax: (33 1) 40 22 04 83
Email: jean-pierre.chang@citepa.org

ITALY
Mr Sergio LA MOTTA
ENEA-Italian Agency for Energy
Environment
Via Anguillarese, 301
00060 Roma
Tel: (39 06) 3048 6407
Fax: (39 06) 3048 3657
Email: lamotta@casaccia.enea.it

FRANCEMr Jean-Pierre FONTELLECITEPA
10 rue du Faubourg Poissonniere
75010 PARIS France
Tel: (33 1) 44 83 68 83
Fax: (33 1) 40 22 04 83
Email: jean-pierre.fontelle@citepa.org

and

ITALY
Ms Daniela ROMANO
ANPA-Italian Environmental Protection Agency
Via V.Brancati 48
00144 Rome
Tel: (39 06) 5007 2310
Fax: (39 06) 5007 2986
Email: romano@anpa.it

GERMANYMr Michael STROGIES
Federal Environmental Agency
P.O.Box 33 00 22
D-14191 Berlin
Tel: (49 30) 8903 2088
Fax: (49 30) 8903 2282
Email: michael.strogies@uba.deJAPAN
Mr Tomoyuki AIZAWA
Sanwa Research InstituteCorporation
Shimbashi Sanwa Toyo Bldg,
1-11-7 Shimbashi,
Minato-ku, Tokyo 105-8631
Tel: (81 3) 3572 9034
Fax: (81 3) 5568 7717
Email: amo@sric.co.jp

ITALY
Dr Michele ARESTA
University of Bari
METEA Research Center
Via Celso Ulpiani 2770126 Bari
Tel: (39 080) 544 2430
Fax: (39 080) 544 2429
Email: aresta@metea.uniba.it&

Consulting

MALAYSIA
Mr Jailan B. SIMON
Malaysian Meteorological Service
Jalan Sultan
46667 Petaling Jaya
Selangor Darul Ehsan
Tel: (603) 7956422 / 79587422 ext.314
Fax: (603) 79550964
Email: jailan@kjc.gov.my

ITALY
Dr Angela DIBENEDETTO
University of Bari, Italy
METEA Research Center
via Celso Ulpiani 2770126 Bari
Tel: (39 080) 544 2078
Fax: (39 080) 544 2083
Email: a.dibenedetto@chimica.uniba.it

MALDIVESMr Ahmed JAMEELMinistry of Home Affairs, Housing andEnvironment
Huravee Building
Male'
Tel: (960) 324861
Fax: (960) 322286
Email: env@environment.gov.mv

31

NETHERLANDS
Drs Jos G.J OLIVIERNational Institute of Public Health and theEnvironment (RIVM)
P.O.Box 1
NL-3720 BA
Bilthoven
Tel: (31 30) 274 3035
Fax: (31 30) 274 4417
Email: jos.olivier@rivm.nl

SLOVAKIADr Katarina MARECKOVA
SHMU
Jeseniova 17,
833 15 Bratislava
Tel: (421 2) 5941 5387
Fax: (421 2) 5477 5670
Email: katarina.mareckova@mail.shmu.sk
SUDAN
Mr Ismail Fadl El Mohamed MOULA
Meteorological Authority
P.O.Box 574
KhartoumTel: (249 11) 778836/37
Fax: (249 11) 771693
Email: ersad@sudanmail.net

NETHERLANDS
Dr Tinus PULLES
TNO
P.O.Box 342
7300 AH Apeldoorn
Tel: (31 55) 549 3762
Fax: (31 55)549 3252
Email: m.p.j.pulles@mep.tno.nl

SWEDEN
Ms Astrid OLSSON
Swedish Environmental Protection Agency
SE-106 48 Stockholm
Tel: (46 8) 698 11 83
Fax: (46 8) 698 15 84
Email: astrid.olsson@environ.se

NETHERLANDS
Drs Harry VREULS
Novem, Netherlands Organisation for Energy
and the Environment
PO Box 17 6130 AA
SittardTel: (31 46) 4202258
Fax: (31 46) 4528260
Email: h.vreuls@novem.nl

UNITED KINGDOMMr Mike WOODFIELD
AEA Technology
CulhamOxfordshire
Tel: (44 1235) 46 3195
Fax: (44 1235) 46 3038
Email: mike.woodfield@aeat.co.uk

NIGERIAMrs Juliana E. UKEJE
Nigerian Meteorological Services Department
Dept. of MET. Service, Federal Ministry of
Aviation, Federal Secretariat
Shehu Shagariway
P.M.B 5012,
Wuse, Abuja
Tel: (234 1) 2633371 / (234 9) 5238357
Fax: (234 1) 2636097 (234 9) 5238357
Email: julie_ukeje@yahoo.co.uk

UNITED STATES
Ms Stephanie F. FINN
Eastern Research Group
P.O.Box 2010
1600 Perimeter Park
Morrisville, NC 27560
Tel: (1 919) 468 7889
Fax: (1 919) 468 7801
Email: sfinn@erg.com

QATAR
Mr Jassim AL-MASLAMANI
Ministry of Energy Industry
Qatar Petroleum
P.O.Box 47
Doha
Tel: (974) 4402500
Fax: (974) 4402865
Email: almaslamani@qp.com.qa

32

UNITED STATES
Ms Elizabeth SCHEEHLE
US Environmental Protection Agency
1200 Pennsylvania Avenue
NW (6202J)
Washington, DC 20460
Tel: (1 202) 564-9758
Fax: (1 202) 565 2254
Email: scheehle.elizabeth@epa.gov

VENEZUELAMr Aldo ANSELMIPDVSA-INTEVEP
Urb. Santa Rosa, Sector el Tambor
Los Teques, Edo.Miranda
P.O.Box 76343
Caracas 1070-A
Tel: (58 212) 908 6929
Fax: (58 212) 908 7801
Email: anselmia@pdvsa.com

IEA
Mr Jean-Yves GARNIER
9, rue de la Federation
75739 PARIS Cedex 15
FranceTel: (33 1) 40 57 66 20
Fax: (33 1) 40 57 66 49
Email: jean-yves.garnier@iea.org

OLADE
Mr Gabriel HERNANDEZ
Latin American Energy Organisation(OLADE)
Ave. Mariscal Antonio Jose de Sucre N58-63
and Fernandez Salvador
OLADE Bldg., San Carlos Sector
Quito, Ecuador
Tel: (593 2) 531 673
Fax: (593 2) 531 691
Email: ghernand@olade.org.ec

IEA
Ms Benedicte RIEY
9, rue de la Federation
75739 PARIS Cedex 15
FranceTel: (33 1) 40 57 66 39
Fax: (33 1) 40 57 66 49
Email: Benedicte.RIEY@iea.org

UNFCCCDr Stylianos PESMAJOGLOU
Martin-Luther-King-Strasse 8
P.O.Box 260 124
D-53153 Bonn
Tel: (49 228) 815 1315
Fax: (49 228) 815 1599
Email: SPesmajoglou@unfccc.int

IEA
Ms Karen TREANTON
9, rue de la Federation
75739 PARIS Cedex 15
FranceTel: (33 1) 40 57 66 33
Fax: (33 1) 40 57 66 49
Email: karen.treanton@iea.org

UNFCCCMr Tleussen TEMERTEKOV
105 - 107 Kennedy Allee
D-53175 Bonn
Tel: (49 228) 815 1537
Fax: (49 228) 815 1999
Email: ttemertekov@unfccc.int
IPCC-NGGIP/TFBMr Taka HIRAISHINational Institute for Environmental Studies
c/o Institute for Global Environmental
Strategies (IGES)
1560-39 Kamiyamaguchi
Hayama, Miura, Kanagawa 240-0198
Japan
Tel: (81 468) 55 3750
Fax: (81 468) 55 3808
Email: hiraishi@iges.or.jp

IPCC-NGGIP/TFBMr Marc Gillet
Mission Interministérielle de l'Effet de Serre
35, rue Saint Dominique
75007 Paris
FranceTel: (33 1) 42 75 87 17
Fax: (33 1) 47 53 76 34
Email: m.gillet@mies.pm.gouv.fr

33

IPCC-NGGIP/TFBDr Carlos LOPEZ
Institute of Meteorology, Cuba
Loma de Casablanca
Ciudad de La Habana
Cuba
CP 11700, Habana 17
Tel: (537) 670711
Fax: (537) 338010
Email:
obilbao@comuh.uh.cu,
cimaa@met.inf.cu

IPCC-NGGIP/TSU
Mr Leandro BUENDIA
c/o Institute for Global Environmental
Strategies (IGES)
1560-39 Kamiyamaguchi
Hayama, Miura, Kanagawa 240-0198
Japan
Tel: (81 468) 55 3750
Fax: (81 468) 55 3808
Email: buendia@iges.or.jp
IPCC-NGGIP/TSU
Ms Kyoko MIWA
c/o Institute for Global Environmental
Strategies (IGES)
1560-39 Kamiyamaguchi
Hayama, Miura, Kanagawa 240-0198
Japan
Tel: (81 468) 55 3750
Fax: (81 468) 55 3808
Email: miwa@iges.or.jp

IPCC-NGGIP/TFBDr Buruhani NYENZIDrought Monitoring Centre(DMC)
Meteorological Service Headquarters
Cnr.Bishop Gaul Ave/Hudson Road
P.O.Box BE 150
Zimbabwe
Tel: (263 4) 77 82 36 / 8172
Fax: (263 4) 77 81 72
Email: bnyenzi@dmc.co.zw

IPCC-NGGIP/TSU
Mr Kiyoto TANABE
c/o Institute for Global Environmental
Strategies (IGES)
1560-39 Kamiyamaguchi
Hayama, Miura, Kanagawa 240-0198
Japan
Tel: (81 468) 55 3750
Fax: (81 468) 55 3808
Email: tanabe@iges.or.jp

IPCC-NGGIP/TFBProf Richard ODINGO
University of Nairobi
P.O.Box 30197
NairobiKenya
Tel: (254 2) 334244
Fax: (254 2) 336 885
Email: R.Odingo@meteo.go.ke

34