Talk:GEOSS AIP AQ Scenario
Change in AQ Scenario Development Leadership -- PDickerson 00:24, 22 January 2008 (EST)
Rudy: Lots of things changed in the last day. The new AIP Contact is John White, AIRNow team, So, please work with John between now and the workshop. I will also be involved and will lend a hand as much as possible.
Re: Change in AQ Scenario Development Leadership -- Rhusar 00:24, 22 January 2008 (EST)
Hello Phil, Thanks for the update. Please note that George Percivall will need to know that John White will be attending the Ispra JRC Meeting. Since there is an AIP telecon on Jan. 22, would it be possible to talk about the AIP on Monday? In the mean time, at George's request we will be adding background material to the OGC AIP website pertaining the Air Quality scenario.
ESIP Participation in Scenario Development -- TKeating 00:27, 22 January 2008 (EST)
Phil et al.,Rudy and other ESIP folks are interested in the 'GEOSS Scenario' for the Ispra meeting. This group would like to help out with this... I've cc'd a few people.
Wiki Workspace -- Rhusar 00:31, 22 January 2008 (EST)
AQ Scenario and Workspace: The air quality scenario for the Ispra Workshop will be maintained on the OGC Site. In addition, wiki workspace for the development of the AIP Air Quality Scenario has been established on the ESIP Wiki. The community is encouraged to contribute their ideas here.
Re: Wiki Workspace -- StuFrye 12:27, 23 January 2008 (EST)
There are many scenarios that cut across discipline areas, but which can be supported by the same set of tools and sensors. The scenarios need to be constructed so that they can be demonstrated on a more global scale than under the AIP phase 1. Restricting the scenario to a single region and single event does not show how the GEOSS offering scales to a global application, so we need to structure the scenarios to take advantage of the global nature of many of our tools and sensor platforms. Air quality assessment should be a combination of modeled results and observation measurements. There should be successive interaction between the models and the observation capabilities so that a feedback loop between the two can be demonstrated. Air quality models should be structured so they accept real observations as well as simulated data as starting point inputs. For smoke from wildfires, the starting point can be calculated by satellite observation from MODIS, Landsat, EO-1 and others. A centroid calculation needs to be provided as a Web Feature Service that would feed the model with fire start locations from these satellites. The model should produce a smoke map or visualization of the progression of a plume. Predicted map should be compared to actual images acquired via sensor web autonomous triggers. The image data should further be processed to create a smoke product...especially the EO-1 Hyperspectral data...as a Web Processing Service. The discovery of these capabilities should be provided by user friendly portals, catalogs, clearinghouses, and registries. The Components and Services Registry needs to be integrated with the Standards registry so they stay in synchronization. The registries should be automatically harvested by the portals to construct the GEOSS offerings. The Portals should also harvest clearinghouse and catalog data instead of being constructed by hand from survey responses supplied by participating organizations. Scenarios should include unmanned robotic sensor platforms and in-situ continuous readout sensors as well as static data sets for mash-ups and visualization mapping.
Re: Re: Wiki Workspace -- Rhusar 14:15, 23 January 2008 (EST)
Very good points, Stu!. The suggestion to make the scenario applicable to any region is indeed appropriate, since (1) Smoke from major fires occur over many areas of the world (2) many of datastes come from the same source (e.g. satellite, global surface weather obs); (3) the sensory-motor functionality, detection-assessment-action, is quite common to all regions and (4) sharing and integrating the resources and methods into a System of Systems is in the spirit of GEOSS. Also, iterative linking of smoke observations and models through data fusion and assimilation into models is also a very important a timely suggestion. Lets see what the observation and modeling communities can do to raise interoperability to the next level (obs-model).
Re: Wiki Workspace - Attach this discussion to pilot scenario page??? -- Davidmccabe 18:38, 25 January 2008 (EST)
Rudy, Stefan, Everyone - how about we move this very useful discussion over to the discussion attached to the GEOSS AIOP Pilot Scenario page? Seems this might be a lot more straightforward. Thoughts??
Adding in the media, public as actors... -- Davidmccabe 00:55, 25 January 2008 (EST)
I've added / fleshed out a number of items to the scenario wiki. A theme I am trying to build in there is that the public are relevant decision makers for AQ problems during a fire. Media is an essential bridge to the public.
I've uploaded a link here and in the Scenario wiki to a one page white paper that John White and I wrote about AirNow during the S. Calif. 2007 fires. (This paper is submission to a USGEO paper on the USG response to the fires.)
Re: Adding in the media, public as actors... -- JWhite 14:45, 25 January 2008 (EST)
This echoes what I was thinking...so I am with you. Others may can provide a better GEO spin?
Re: Adding in the media, public as actors... -- PDickerson 14:47, 25 January 2008 (EST)=
David: Good comments! I'll leave it to Rudy and John as to how best to incorporate them, but I think your comments are really at the root of the whole scenario. You made me think of a few comments of my own. I believe someone on one of the ADC calls pointed out the need for "large scale" scenarios, i.e. scenarios that cross national boundaries and are globally applicable. I wonder if we might take a lesson from the Alaska wildfire example, which Jim Szykman has examined in great detail. That is almost a trans-national event, even though Alaska is technically a US state. In that scenario, the fires started far from the typical population centers of the US, yet the ground-level impacts were felt in the Appalachian areas of Kentucky and maybe Georgia and Alabama. So, to me that says we should include transport in the scenario. That automatically brings in satellite data -- both met and air quality -- and perhaps even a "fire detection" function. The SERVIR case study from May 2007 is also an interesting one. Basically, a smoke event ocurred in Central America. Some thought it was a "toxic cloud" coming over from Africa. SERVIR was able to quickly dispel that notion using back-trajectory models and visible sat. imagery. So, it was attributed to local burning. However, there was not an "AIRNow-like" component by which to issue any public health info. Lastly, I wonder if we should include public health information in the scenario. It is far-fetched, but I think it should be part of "the dream". I would end the scenario with an examination of hospital admissions, doctor's office visits, etc. That would allow a feedback loop for future scenarios in which better public information might lead to fewer hospital admissions. The only thing is -- do we have health agencies in GEO? Not sure. -- Phil
Re: Re: Adding in the media, public as actors... -- Davidmccabe 14:48, 25 January 2008 (EST)
I don't think we are out of bounds to say we would like to see the public health folks using our data. If they are not participating in GEOSS now (and in the USG, health participation is weak) that does not mean we should not push for it. Further, I don't think of USG health agencies as the ones moving the ball forward on AQ epi work (or at least they don't have a monopoly). The GEOSS goal is to push data out to users, not just others 'within'GEOSS. It seems like the AIRNow 2007 Calif event and the SERVIR 2007 event are probably the best stories out there for real-time or near-real-time AQ response to fires. Other examples??? That makes combining SERVIR with AIRNow rather exciting. Actually doing GEOSS !!!! The transboundary events are certainly very interesting. But the strong exposures are more local... at a scale where transport really needs BlueSky RAINS. Is that type of capability existing at SERVIR? Can it be made interoperable so that it can be? Since we are building our perfect geoss machine of the future, it seems like we should pitch for such capabilities.
Re: Re: Re: Adding in the media, public as actors... -- PDickerson 14:50, 25 January 2008 (EST)
Good question on BSK. I don't know the answer! I was thinking very simplistically -- using SERVIR as a "fire spotter", then perhaps doing some sort of modeling to guess where a smoke plume was going. I think BSK has that capability, but I'm not sure that SERVIR is using the same models. In any event, I think the concept is valid -- using satellite to detect fire, then using a compilation of tools and data to predict the plume, followed by ground truthing to measure plume impact and public health. So, the only transboundary phenomenon I was thinking of was transport of the smoke. In Jim's example, the smoke was high above the ground once it left Alaska, but had measurable PM2.5 concentrations in the SouthEast. From a purely health-based perspective, EPA couldn't be of any use while the smoke was aloft, but in the future it would be great to know it was coming! Anyway, I was using Alaska as an example only because the California fires were on such a small scale and don't exactly scale up to a GEOSS example all by themselves. Also, BSK might be the perfect tool to plug in, but I'm not well versed on it. I bet Rudy or Stefan can address that quite well.
Re: Re: Re: Re: Adding in the media, public as actors... -- Sfalke 14:50, 25 January 2008 (EST)
Incorporating Bluesky forecasting would be valuable. In one of our NASA projects as part of NASA's Sensor Web Program, we're working on the use and development of interoperable web service interfaces to foster information flow between sensors and models. The Bluesky model is one of our target models. The group at the Forest Service and Sonoma Technology is presently redesigning the Bluesky framework so that it is modular (and therefore more suitable for integration in a service oriented framework). There's still a lot of work to be done before the model components are "interoperable" or can be "plugged" in but I like the idea of including smoke forecasts and long range transport in the GEOSS scenario to see what could be done for the pilot. The input data we've been working with include surface data, satellite observations (the usual MODIS but also the "taskable" hyperspectral EO-1), and a NASA-Ames UAV (which is somehow involved in the SERVIR project - so another link between those efforts) I'll work on putting together a write-up and posting it to the wiki.