Difference between revisions of "Talk:TrajectoryService"

From Federation of Earth Science Information Partners
Line 17: Line 17:
 
:Rudy: The key is to have a service that can take the wind forecasting and the current air quality data and to predict the migration of pollution. Do you have such chainable geoprocessing service available? [[User:LDi|LDi]]18:22, 15 June 2006 (EDT)
 
:Rudy: The key is to have a service that can take the wind forecasting and the current air quality data and to predict the migration of pollution. Do you have such chainable geoprocessing service available? [[User:LDi|LDi]]18:22, 15 June 2006 (EDT)
  
===........GRutledge: Re:Ldi:Re: Compound Trajectory Service===
+
===........GRutledge: Re:LDi:Re: Compound Trajectory Service===
 
::Hi Liping- That's a great question- I mentioned the EPA HYSPLIT model in my last- I only get the input data used to drive that model but if I understand Rudy correctly (and correct me if I'm wrong), he's thinking of a simple trajactory service that uses wind to indicate approximate downstream coverages wrt time.  The generation of the amount and coverage of point particulate matter or e.g., ozone etc., is too complex for this demo.  [[User:GRutledge|GRutledge]]18:22, 15 June 2006 (EDT)
 
::Hi Liping- That's a great question- I mentioned the EPA HYSPLIT model in my last- I only get the input data used to drive that model but if I understand Rudy correctly (and correct me if I'm wrong), he's thinking of a simple trajactory service that uses wind to indicate approximate downstream coverages wrt time.  The generation of the amount and coverage of point particulate matter or e.g., ozone etc., is too complex for this demo.  [[User:GRutledge|GRutledge]]18:22, 15 June 2006 (EDT)
  

Revision as of 06:46, June 16, 2006

  • To add to the discussion, log in to DataFed wiki
  • Begin each entry with ====Username: Subject====
  • To respond, add dots ====......Username: Subject====
  • Indent response text by adding : for each tab.
  • Sign your entry by ending with '~~~~',



RHusar: Compound Trajectory Service

Hi - On Fridays (June 9, 2006) GSN telecon, I appreciated Ben bringing up the trajectory calculation as a component of the IGARSS'06 Denver GSN demo. Such a demo would utilize the real-time/forecast model winds from Unidata, historical wind data from NCDC NOMADS and processing and integration routines through the Wash U. and Florence groups. The result of this collaboration could be a trajectory server system that would allow diagnostic air quality tranport analysis in both forecast and hindcast mode. All of this, of course, connected through OGC interfaces. This is a perfectly doable undertaking for Denver since much of the groundwork and connectivity has been done for GSN Beijing. With regard to the interoperability software, the key next step is to establish a robust data access interface to Unidata and NOMADS through the THREDDS-WCS-netCDF data access services. Below is my perception of the missing pieces and other issues for our joint consideration:

  • For trajectory calculations, the WCS query has to allow the bbox (XYZ) to be a 3D BOX, specified in lat/lon, elevation (or pressure) dimensions. Furthermore, the time query should be a time range (say few days). The resulting netCDF-CF file should contain the 4-D arrays (XYZT) for U, V, and W for the requested time window.
  • As part of GALEON I, we explored and reported the test implementation of such a WCS query, as applied to the GFS model dataset in THREDDS. http://galeon-wcs.jot.com/WikiHome/Implementation+Progress+Page/DataFed-GALEON_Rep060215.pdf

see section : WCS for 4-dimensional netCDF Data. I can conceive that the Unidata/NCDC, Florence and DataFed implenetaions of WCS service for this purpose may be different. I think such diversity at the server back end is good. So we are looking forward to interacting with you all on comparing and evaluating our respective WCS implementations. The key is that the query is according to the 3D bbox and time range and the returned netCDF file contains the 4D cube for U,V,W winds in a regular netCDF grid.

  • The global 1 degree resolution model seems to be a good candidate test dataset. As I understand GFS is available through the real-time - forecast Unidata, THREDDS, as well as from the NCDC NOMADS-THREDDS server. Also we all have used this dataset for the Beijing demo.

From our side, at CAPITA, the key person for this activity is Kari Höijärvi (hoijarvi@me.wustl.edu). Looking forward to stepping up the activity. Regards,Rhusar18:22, 15 June 2006 (EDT)

....BDomenico: Re: Compound Trajectory Service

Rudy, This sounds really exciting. But I should clarify that what you propose goes far beyond what I had in mind when I brought up the topic of forecast model output in the GSN telecon. What I was thinking of was just a demonstration of the sort of WCS connection to weather forecast model output that was preparted for the Beijing demo. Of course, if the parcel trajectory demo can be arranged, that would be terrific!! BDomenico18:22, 15 June 2006 (EDT)

....LDi: Re: Compound Trajectory Service

Rudy: The key is to have a service that can take the wind forecasting and the current air quality data and to predict the migration of pollution. Do you have such chainable geoprocessing service available? LDi18:22, 15 June 2006 (EDT)

........GRutledge: Re:LDi:Re: Compound Trajectory Service

Hi Liping- That's a great question- I mentioned the EPA HYSPLIT model in my last- I only get the input data used to drive that model but if I understand Rudy correctly (and correct me if I'm wrong), he's thinking of a simple trajactory service that uses wind to indicate approximate downstream coverages wrt time. The generation of the amount and coverage of point particulate matter or e.g., ozone etc., is too complex for this demo. GRutledge18:22, 15 June 2006 (EDT)

....GRutledge: Re: Compound Trajectory Service

Hi Rudy- I like you plans for this demo and the fact it could continue to be a persistent service. Two suggestions- given the potential sub-setting capabilities, we also have the 1/2 degree GFS, and the NAM (as you know- formally the Eta), input variables that are used for the EPA Hysplit AQ model. As far as I know, we're the only other site getting these input (analysis) variables (besides EPA of course).
Dan Swank is the point man here once again and I appreciate his outstanding efforts in this this regard. We'll be ready around here to participate. Thanks to all- for all the forward movement on these activities! GRutledge18:22, 15 June 2006 (EDT)

........RHusar:Re:Re: Compound Trajectory Service

Hey Ben et al, I think that for the Denver GSN Demo we can/should do more than showing the wind fields for a specific time. For the interpretation of AQ data such vector fields of current or forecast winds are of limited use. We need airmass history, i.e. trajectory information.
For the Denver demo I had in mind a simple trajectory service that calculates forward and backward trajectories for a specific location and time. With such a service, one can answer the diagnostic questions of where the (dirty) airmass came from or is going to. Given such a trajectory service, using WCS access to distributed 3D model wind data, one can build a simple trajectory browser as a thin client using HTML and javascript, e.g. the DataFed trajectory browser, http://webapps.datafed.net/datafed.aspx?dataset_abbr=ATADV . When you click on any of the monitoring sites the corresponding trajectory is displayed. The user can also change the trajectory arrival time. Note that the current browser uses a back trajectory database, pre-computed for specific receptor locations and dates. The new elements for the Denver demo would include:
  • Real-time calculation of trajectories
  • Remote access to forecast (Unidata) and historical (NCDC) winds
  • WCS and netCDF-CF standards-based data access
  • Persistents of the compound trajectory service as a network of chained services
In order to promote open communication and to organize the content Erin Robinson has set-up a workspace on the ESIP wiki. Relevant content from this wiki will also be transferred to the OGCnetwork GSN workspace. Please note that this communal trajectory service chaining development is part of many different projects, in addition to the GSN Denver demo. We have transferred this e-mail thread to the trajectory service discussion page. Please feel free to post your comments to this discussion page, however you can also reply through e-mail and we will transfer to the wiki. Rhusar09:42, 16 June 2006 (EDT)