View source for Talk:TrajectoryService

{{edithelp}}
===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,[[User:Rhusar|Rhusar]]18: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!! [[User:BDomenico|BDomenico]]18: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? [[User:LDi|LDi]]18: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.  [[User:GRutledge|GRutledge]]18: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!  [[User:GRutledge|GRutledge]]18:22, 15 June 2006 (EDT)

===RHusar:Denver Demo 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. [[User:Rhusar|Rhusar]]09:42, 16 June 2006 (EDT)
===.....BDomenico:Re:Denver Demo Trajectory Service===
:Hello, This sounds great to me.  But I want to make sure I understand whether anything else is needed in terms of weather forecast output for the short term (July) demo.  From your description, it sounds like you can calculate the forward trajectories using the real-time forecast model output that's already being served at Unidata. 

:For the longer term use case scenario, I would like to know whether it would be useful to be able to run a high resolution local forecast model in the area where an event is taking place.  As you can see on the Unidata home page (GEMPAK Mesoscale Model Display), we are running such a model on a regular basis.  In our case, the model is focused on a "region of interest" where there is a high likelihood of precip.  But "region of interest" could be based on a contamination event as well.  These local models run at resolutions closer to those typical of the traditional GIS community.  Let me know if this is of interest (in the longer term, not for the July demo).  Currently the output of the local models is not available via WCS but I've done enough experimentation with the WCS server on my laptop to convince myself that it can be done if it would be useful. 

:By the way, this is the sort of thing I had in mind when, in the GALEON telecon, Rudy came up with the idea of GALEON putting together some scenarios that involve the interplay of more than one OGC service (real-time sensor data, WCS, WFS, catalog services, processing services, etc.).  I think we are at a point where it is important to consider how these services interact with one another and which ones to use when. [[User:BDomenico|BDomenico]] 16 June 2006 (EDT)
===..........Rhusar:Re:Denver Demo Trajectory Service===
::Ben, All, Thank you for your continued interest and support for the trajectory services as a practical illustration of interoperable services. As we see it a simple service chaining diagram for the demo is shown on the [[Component Web Services and Service Chaining]] wiki page

::No, we definitely do not have all the pieces for a simple service based trajectory demo for the GSN Denver.  The particular work that we need to finish before we can set up the simple trajectory service includes:
 
::1. WCS Wind Data Access: 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. It would be good to have the latest version of the links to the available WCS services from Unidata/NCDC so that we know where we are. Hope to hear from Dan Swank and Ethan Davis regarding the WCS status for 4-D wind data access. 
 
::2. Wind Data Source: Glen's note confirms that the GFS model output would be a good starter dataset for the trajectory demo. A few questions: Does the NOMADS 0.5deg GSN include wind data forecast as well as historical data? For redundancy should we link to both Unidata and NOMADS forecast? Does GFS include u,v, and w winds or just u,v winds at the model elevations? (if so, the vertical wind, w would need to be calculated from the convergence.)  Can the time window be two weeks, i.e. wider than the time range of a netCDF data granule (file)?
 
::Ben, your longer term scenario of running a high resolution "floater" model at specific regions of interest, e.g. major forest fires, is indeed of great interest to us and to the AQ analysis and regulatory communities. We can follow this topic after the Denver demo. Regards,[[User:Rhusar|Rhusar]]18:03, 18 June 2006 (EDT)
===...............EDavis:Re:Denver Demo Trajectory Service ===
:::I believe that currently the TDS does not make any 4-D fields available through WCS. It makes XYT fields available and XYZT fields if the z dimension has a single value but otherwise XYZT fields are not presented through WCS. John will have to give the current status but I'm pretty sure it is on the list of issues to address. [[User:EDavis|EDavis]] 19 June 2006 (EDT)
===...............SNativi:Re:Denver Demo Trajectory Service ===
:::Hi Ethan and Rudy, A possibility to return 4-D wind data is to use the WCS-G server; it is a WCS 1.0 implementation which supports ncML-GML v. 0.7.3. A ncML-GML document consists of both a ncML representation of the netCDF dataset and a coverage view of the same dataset encoded in GML v. 3.1.1 [[User:SNativi|SNativi]] 20 June 2006 (EDT)