Great Lakes Regional Toxic Air
Emissions Inventory
Steering
Committee Conference Call Minutes
December 13, 2006
Participants
Illinois: Buzz
Asselmeier
Indiana: Jon Bates
Michigan: Dennis McGeen
and Allan Ostrander
Minnesota: Chun Yi and
New York: Carlos
Mancilla
Ohio: Tom Velalis
Ontario: Cong Doan
Pennsylvania: Karen Gee
Wisconsin: Orlando Cabrera-Rivera
GLC: Jon Dettling
EPA:
Other: Mark Young
Chun Yi announced that Dan Steber
will be leaving MPCA. He's taken a position with a petroleum refinery. Chun Yi
commented on how great a job he's been doing and that he'll be missed.
Orlando mentioned the
need at the end of the call to discuss agenda items for the next meeting and to
set a time for the next call.
Mark posted two documents the
night prior to the call. One was a spreadsheet with a tab for each of the
tables in the database design and gives a detailed view of each of the fields
in the database.
Mark mentioned that each table has
had assigned at least one unique key. The RIDs are used as a primary key to
join tables. This is a good practice to help performance. There is a database table,
where separate inventories can be defined and serve as an umbrella for data in
other tables. In most cases, the data elements are very similar to NIF 3.0.
Orlando asked whether
locational coordinates would be included at the source level as well as the
Device level. Mark mentioned that he's spoken with Pete at the GLC who has some
ideas to implement GIS with the database by using a standard system called
PostGIS, which integrates with PostgreSQL. This shouldn't be radically
different from how geography has been represented in the past. Mark asked
whether stacks might also be desired to have geographic coordinates in some
cases.
Orlando raised the
issue of using the source coordinates to
implement QA/QC routines used in the past ,
such as making sure that the sources are in the correct State and or county.
Tom mentioned that their approach
in their database is to have geographic information at both the source
and stack level. There are two built-in quality assurance steps. One is that
the source and stack are in the same county. The other is based on the EPA's QA
checks for geographic data.
Orlando raised that
their has been some discussion about moving
away from using the current geographic prefix to the
source ID when importing data into the regional repository. Mark
responded that he believes that the way this is currently represented their
shouldn't be an issue in the current case because the county codes will be
unique, even if their IDs are
not.
The source ID field was set up to
have up to 15 digits to accommodate Ohio.
Orlando
wondered whether that was still the case. Tom noted that he used to use their
15-digit source codes and then add a two-digit state code. This is no longer
the case and 15 digits would be plenty to accommodate their codes. Orlando emphasized the need
to be able to accommodate TRI
source IDs without needing to alter the
codes unnecessarily. The current NEI
format for TRI ID allows 20 characters.
Chun Yi asked about the length of
the comments fields. She prefers to have longer comments if possible, as she
often adds much information in these fields. Mark mentioned that we can easily
make the comment fields in our database larger and these can be truncated to 40
for submitting to EPA. This is a less critical concern for notes than for certain
other fields, where it would be advisable to not exceed NEI lengths. Chun Yi
noted that the description fields could also be lengthened, if possible.
We could have both a comment field for our purposes, and a shorter
description field for NEI use.
The proposed new emissions
table includes information on the emission factors used in the
calculations. Chun Yi commented that it
seems to her that she feels that having a separate emission factor table is a
strength of the current RAPIDS and she doesn't want to see that go away. Mark
noted that the emission factor field in the emissions table is different than
the emission factors table, which would still exist and isn't shown in the
current chart. The factor fields in the emissions table would be populated by
the emission calculator when the calculations are done to provide a record of
which factor was used. Chun Yi questioned whether this would use unnecessary
database storage. The group didn't feel this way and Cong in particular noted
that this feature would be very useful for them. Orlando pointed out that Wisconsin's
EI system includes an emission factors used table. He will send a copy of the
table for people to see. After
hearing that it shouldn't be a major storage or performance drain, Chun Yi agreed
that it would be very useful to have the emission factor information in the
emissions table.
Mark pointed out a new feature in
the activities and emissions tables. He's added what he's labeled as a
"scenario code" this would allow the user to run calculations with
certain specifications and to keep these calculated results separate from other
data. Data can be tagged in this way to keep it separate. For example, the same
database could have both annual and seasonal data. People in the group liked this
concept. They will continue to thing about it's implementation. In combination
with the "inventory code," this would replace the "reference
code."
Mark mentioned that there are some
concerns with using start and end dates as key fields, as he currently has in
the activities table. He's considering altering this, such as by adding a
separate table that would have time periods. Orlando explained that currently the start
and end dates for activities must match or they won't be computed. Mark
wondered whether the group would find value in having the ability to compile
inventories with some variation in the time period for the inventories
(seasonal, monthly, etc.) or for the time period of emissions from a given
source (operating only during a portion of the year). There was some interest
in addressing this.
Mark will look for calculation
methodologies in the 2002 report on the GLC website to begin designing ways to
implement in the new system's calculation routines.
Carlos inquired about the question
about timeframe for program completion and requirements for the 2005 inventory.
Jon responded that it is anticipated that data import/export functionality
would exist by this spring or early summer and that calculation tools and data
management tools would be added following that, with a highly functional
version completed perhaps by the end of 2007, which would continue to be
improved into 2008 and beyond. For the 2005 inventory, Jon does not anticipate
requiring states to submit their data in the old RAPIDS format, although that
would be allowed for those who find it convenient. The new database for 2005
will likely be in the new format and either RAPIDS 2.4 or NIF3 files will be
accepted, even though that may push our timeframe back a little.
Tom noted that Mark had said
something about mass balance calculations. He wondered whether anyone would use
mass balance and if this is needed. Tom recommended sticking mainly to an
emission factor approach. Mark asked about speciation. Tom suggested that this
is probably not needed; the few speciation profiles that are used can be
converted to emission factors for the relevant compounds. Orlando noted that this may not always be a
simple matter and is something we should address at some point.
Cong asked whether a data code
field would be included and Mark noted that he though it probably would.
Cong also asked about he heat content field in the rap_processes table. Mark
responded that EPA has a rigidly defined unit for this field, such as MMBTUs.
We may be able to be mode flexible in our definitions.
Orlando noted that it
would be valuable to have, for example, the ability to link the source table
directly to the emissions so that the user could quickly query that table for
source level emissions. There may be other such cases where there are certain
common query types that could be made easier by such changes in the structure.
Mark mentioned that there may be many ways to solve such problems, including
creating "views" of the database that would have these data elements
included.
Chun Yi asked about some of the
notation on the ERD that Mark sent. Mark said that the crow's feet at the end
of many of the lines symbolizes 1-to-many relationships. The cross lines
represent required relationships, where the open circle represents optional
entities. For example, stacks are optional.
Mark would like feedback at any
time. The sooner the better. By the time of the January meeting in Chicago, Mark plans to
develop a plan of how the current RAPIDS functionalities would operate on this
new database.
Jon summarized the content of an
email he sent to the group regarding his presentation the prior week to the
benzo(a)pyrene GLBTS group. In short, a few of the things to follow up on are
the remaining high FCCU sources, the coke oven emission issue, and developing a
qualitative assessment of BaP emission "trends." Jon will prepare a
new draft of the report, incorporating some of these items and they can be
discussed and finalized at the next in person meeting, with the report being
finalized in mid-february. Jon will also contact Jon Bates from Indiana to inquire about the work they
performed on Coke Oven gas emissions. Indiana
may be able to provide additional information that other states could use
in quantifying their B(a)P emissions.
Next call will be Jan. 10, 2007