NEISGEI Reporting

Quarterly Report

1 Relevance

1.1 List number of interactions (e.g., phone conversations, e-mails, face-to-face communications) with key decision makers and expected users of your project's products.

1.1.a Number of Phone Conversations
(1) Greg Stella, Alpine Geophysics

1.1.b Number of E-mails
(1) Tom Pace, EPA\ORD

1.1.c Number of Face-to-Face Communications
(2 group meetings)

• We helped organize a NO2 Workshop (see http://wiki.esipfed.org/index.php/Workshop)
• Presentation and discussions at TF HTAP Workshop (see http://datafedwiki.wustl.edu/index.php/2007-10-16_HTAP_Juelich HTAP Meeting)

1.1.d Number of Other Communications and Types

2 Quality

2.1 Are you collecting data that is in conformance with formally established Standard Operating Procedures (SOP) within your research community?
No

2.2 If no, briefly explain in several sentences why you're not (e.g., there is no established protocol and the project is developing its own SOPs).
We are not collecting data but are working with data that follow standard data schema and formats. One of the objectives of our work is to help establish standard data interfaces for uniformly accessing and working with distributed, heterogeneous data sources.

3 Performance

3.1 Cite any meetings, symposia, conferences, or workshops at which you presented your project.

• EPA-ESIP NO2 Workshop (),
• HTAP Meeting, Juelich, Germany|TF HTAP Workshop Forshungszentrum Juelich, Oct 17-19, 2007, Juelich, Germany
• NASA briefing,
• EPA OEI Symposium,
• ESIP Federation Winter meeting

3.2 Did you achieve progress toward scalability as outlined in your implementation plan (e.g., is information/data able to be expanded/contracted spatially and temporally)?
Yes

3.2.a If yes, briefly describe. If no, briefly explain how it will be addressed next quarter.
Through the use of Open Geospatial Consortium data access standards (WMS, WCS, and WFS), emissions data are accessible through spatial and temporal filtering. The output from the data access service can be fed into data aggregation web services to change the spatial and temporal dimensions (e.g., spatial allocation, daily to monthly time average).

3.3 Did you achieve progress toward integration (e.g., is information/data from this project able to be combined with information/data from other complementary sources)? Yes

3.3.a If yes, briefly describe. If no, briefly explain how it will be addressed next quarter. Examples:

• NEI point NOx emissions are overlaid on a map of satellite OMI derived NO2 column density estimates
• A service was developed to extract gridded data values (e.g., from a satellite image) at a set of points (e.g., surface monitoring locations or powerplant locations)

3.4 Did you achieve progress toward interoperability (e.g., is data being time and date stamped, longitude and latitude stamped, height/altitude/depth stamped, and is data being given metadata tags)?
Yes

3.4.a If yes, briefly describe. If no, briefly explain how it will be addressed next quarter.
We have implemented data access through Open Geospatial Consortium (OGC) interoperability standards, such as the Web Map Service (WMS), Web Coverage Service (WCS) and Web Feature Service (WFS). Multiple visualizaiton/analysis components are combined in mashup applications, such as the DataFed Browser, GoogleMaps, OpenLayers, Adobe Flex Charts, LifeRay Portal and Wikis. We are using web service standards to create service workflows and have demonstrated interoperability between independent servers on DataFed and NEISGEI. We are semi-automatically translating metadata records into common metadata standards, FGDC and GCMD SERF.

4 Project Management

4.1 Are you on track in completing scheduled work tasks?
No, some tasks are behind schedule

4.1.a If No, please explain delays.
Technical difficulties on both IT (learning curve with open source software) and data processing (data availability, access methods, geographic reprojection, and handling large sizes). All issues that the project is addressing but that generated new and in some cases, unanticipated, challenges (see lessons learned below).

4.2 Problems encountered and lessons learned during the quarter.

4.2.a Were there any problems encountered or lessons learned regarding funding vehicle management/money distribution?
Terry, can you address this one?

4.2.a.1 If yes, please describe what you learned.

4.2.b Were there any problems encountered or lessons learned regarding the research process?
Yes

4.2.b.1 If yes, please describe what you learned.
A challenge nas been how to minimize the burden on data providers to become connected to the interoperable network. Our project has gone through the process for multiple emissions datasets and implemented interfaces on our server to connect but encounter similar issues in data format (e.g., data structure, projection information) that require substantial effort to address. An improvement in the process would be achieved if the community set guidelines for achieving interoperability and tools to help address the interoperability issues (such as standing up a WCS or reprojecting CMAQ output)

4.2.c Were there any problems encountered or lessons learned regarding the subject matter?
Yes

4.2.c.1 If yes, please describe what you learned.
New insight was gained in comparing satellite and modeled emissions and surface monitoring (particularly the CEM data). The tools being developed through the project need to become more accessible (better user interfaces, easier to add data) to foster broader use.

4.2.d Were there any problems encountered or lessons learned regarding information technology?
Yes 4.2.d.1 If yes, please describe what you learned.
We continue to face the challenge in web service and application development. Open source and commercial software are providing tremendous capabilities (e.g., wikis, portals, OpenLayers, GoogleMaps, MapServer, etc.) but we usually need to extend their capabilities which normally requires a larger investment of time than anticipated. Nonetheless, the availability of these software allows us to create new applications at a lower cost than if a stand-alone system were custom developed from scratch.

4.2.e Were there any problems encountered or lessons learned regarding equipment?

4.2.e.1 If yes, please describe what you learned.

4.2.f Were there any problems encountered or lessons learned regarding new methodologies?

4.2.f.1 If yes, please describe what you learned.

5 Comments

5.1 Please add any additional comments below.

Final Report

1. Relevance

1.1. Interactions with key decision makers. List decision makers and their feedback.

• GEIA community - sees tremendous potential in interoperable infrastructure to integrate data
• Amber Soja - interested in applying fire emissions analysis methods to dynamic web applications
• Tom Pace - web access to various satellite derived fire location datasets for input into emissions estimates
• Doug Solomon - new ways to delivery NEI data

1.2. Expected uses by decision makers. Please describe.

• Data Access
• Data Visualization
• Data Analysis

1.3. Unexpected uses by decision makers. Please describe, if any.

1.4. List project collaborators (person and organization), and nature of collaboration.

• Terry Keating, EPA\OAR (emissions comparisons, data sources/access)
• Rudy Husar, Washington University (satellite data access and analysis)
• Gregory Stella, Alpine Geophysics (data sources/access, emissions user, application tester)

1.5. List resources (i.e., money, equipment, data, methods, models) contributed by collaborators. List number of interactions (e.g., phone conversations, e-mails, face-to-face communications) with key decision makers and expected users of your project's products.

2. Quality

2.1. List all Quality Assurance, Quality Control, and technically relevant guidelines and methods, and SOPs used during your project that may be used "as is" by other projects in the future, or potentially used "as illustrative examples" to develop other project specific SOPs.

• Implemented OGC data access services
• Process for establishing OGC services by data providers
• Web applications for visualization, exploration and analysis
• Process, components, and code for building web applications

2.2. Describe any lessons learned regarding QA of the equipment used and its performance.

2.3. Describe limitations of project's data for inference, especially in terms of error propagation and scalability (to help other user(s) of these data to determine what it can be used for).

2.4. Describe strength of project's data for inference.

3. Performance

3.1. Describe how you met the project's proposed objective/goal. If you did not, please explain why.

• We have implemented data access through Open Geospatial Consortium (OGC) interoperability standards, such as the Web Map Service (WMS), Web Coverage Service (WCS) and Web Feature Service (WFS).
• Multiple visualizaiton/analysis components are combined in mashup applications, such as the DataFed Browser, GoogleMaps, OpenLayers, Adobe Flex Charts, LifeRay Portal and Wikis.
• We are using web service standards to create service workflows and have demonstrated interoperability between independent servers on DataFed and NEISGEI.
• We are semi-automatically translating metadata records into common metadata standards, FGDC and GCMD SERF.
• We have not achieved as much direct user applications external to the project.

3.2. Describe your project's ability to characterize human health and/or environmental outcomes quantitatively.

3.3. Describe the project's key deliverable(s).

Scalability, integration, and interoperability are important characteristics that help turn the project's work products into "services" within the context of a service-oriented architecture.
The NEISGEI project aims to provide interoperable interfaces to emissions related data and to build web applications to explore and analyze the data in order to foster integration and multiple spatial and temporal resolutions. The objective is that throgh standard interfacesand applciations build on top of the interoperable infrastructure, emissions data users and analysts can minimize the effort needed to find, access and process data before it is ready for analysis.

3.4. Scalability:

a. In its present form, are your data, models and/or services scalable (e.g., able to be expanded/contracted spatially and temporally)? Please explain.
Through the use of Open Geospatial Consortium data access standards (WMS, WCS, and WFS), emissions data are accessible through spatial and temporal filtering. The output from the data access service can be fed into data aggregation web services to change the spatial and temporal dimensions (e.g., spatial allocation, daily to monthly time average).

b. Are there identifiable scalability barriers (e.g., data, models, and/or services are so computationally intensive that it would require more computing capacity (e.g., storage, speed) than is currently available, so either more capacity or more resources are needed to make the algorithms more computationally efficient)? Please explain.

3.5. Integration: Was information or data obtained in this project integrated with data obtained from other sources? Please explain.
All data was accessed from other sources. In most cases, we downloaded the data and served through OGC interfaces. Satellite data were obtained through NASA's Giovanni which provides standard interfaces, meaning no download and re-serve was necessary.

3.6. Interoperability:

a. Is information or data obtained from this project in a format such that it can be combined with other information or data? Please explain.
Yes, the data are accessible through OGC standard requests in a variety of formats ranging from jpg, gif, to csv, to netCDF and KML.. Many of our developed web applications integrate data from multiple sources:

• NEI point NOx emissions are overlaid on a map of satellite OMI derived NO2 column density estimates
• A service was developed to extract gridded data values (e.g., from a satellite image) at a set of points (e.g., surface monitoring locations or powerplant locations)

b. Is the software you used capable of exchanging data between different programs and reading and writing the same file formats?
We make use of the DataFed infrastructure that provides data adapters and the ability to create custom adapters for translating heterogenous data sources into a uniform framework for analysis and then for "exporting" in a variety of common formats for continued "down stream" access and processing by others.

c. Number of new user requirements for your software or hardware.

d. Problems incurred in meeting new user requirements.

e. Are all data time and date stamped? If not, why not?
Data have their temporal and spatial coverage described in XML-based metadata. This is accessible through standard metadata for data catalogs (FGDC, GCMD) and standard OGC requests, such as DescribeCoverage and GetCapabilities.

f. Are all data longitude and latitude stamped? If yes, what is the spatial resolution (if multiple resolutions, provide range)? If not, why not?
Our project does not serve the role of data provider. Instead, we provide standardized access to data and tools to analyze the data. Therefore, the data we work with ranges from regional emissions inventories (annual average; point, area, grid) to global emissions models (monthly resolution; 0.5-1 degree resolution) to satellite imagery (global; 250m-30km grids).

g. Are all data height/altitude/depth stamped? If yes, what is the spatial resolution (if multiple resolutions, provide range)? If not, why not?
Not in all cases. Modeled output does capture altitude but others are described in free text: emissions inventories (surface) and satellite data (column densities)

h. List Metadata Standards used (e.g., Global Change Master Directory - [1]).

• FGDC
• GCMD SERF

4. Project Management

4.1. Key Learning: What did you learn over the course of your project regarding process/project management that is important to pass along to AMI/EPA GEO management and future PIs?