Poison Use Cases

I thought it would be a good idea to document the use cases that Peter has been developing for PoiConDAI/PoiCenDAI. I did this because we've needed it for a long time and also because we're now actively engaging the AAPCC/BioSense epis on what functionality is required.

Documenting our use cases and revising them as necessary let us all build from a common picture.

View the use cases on the phgrid wiki.

Poison Visualization requirements

John and I met with Drs. Tokars, Rhodes and Hicks to go over some possible requirements for how to update the Poison Data Aggregation visualization (v1 available here).

The initial suggestion is to update the time series line graph to include a line representing the rolling 28 day average (14 days back and 14 days forward) as well as a star marking any data point that is deemed statistically significant.

This basically means that the current usage of google charts will get updated. Currently candidates are: jQuery, dojoX, dundas, rweb, flot

Well, we know it works in tomcat.

I have confirmed that the old version of poicondai (the CO centric version that you can see on the demo server now) will run in tomcat. Also, the lab engineer, Dale, has already whipped up a VM with SQL Server for testing, so that is awesome, and I should be able to test on it tomorrow.

Meanwhile, I have finished testing and creating an interface on top of the NPDS Axis service I had created, and now I have created a new project called npdsgmaps to essentially act as the mediator between the webapp, the gmap-polygon libraries, and the npds service. Thus it will make sure the time series of the polygons get populated appropriately, and that all the extra data for the web services gets passed in without the polygons having to worry about it. I am tentatively hoping I will get basic data in a rudimentary poicendai-map program (IE, a state and/or some zipcodes showing data) by tomorrow evening... but that is a lot of tentative and hope, I'll let you know where I am :D.

Cheers.

PoiConDai II, revenge of PoiConDai

So, Poicondai II (Which I think is going to be called "PoiCenDai" because they are just called poison centers not poison _control_ centers anymore) is in the works.

The new service that will be feeding PoiCenDai is going to be giving back a lot more complex information, namely count aggregations based on region and time. Dr. Jeremy Espino has recommended Apache CXF as the service handler (which is basically the next generation of Apache AXIS, which will allow for this new PoiCenDai to work with globus that much more seamlessly should we need to distribute its operations on the grid) and using JAXB as the object marshaller (At least I am anticipating this because the last poison center webservice returned the data as an XML "any" stream with a "schema" stream)

Thus, the PoiCenDai service is going to need to take a command, determine the output type, marshal it all out, and then take the results and filter them into the appropriate regional polygons which were also drummed up with the help of the Gmap Polygon libraries.

Thus it's becoming one of those little moments where it's awkward figuring out where to start, whether I delve in with the new technologies for objectifying the PoiCen data, or start planning ways to keep methods for stuffing PoiCenDai data into polygons simple and relatively agnostic to JSPs.

I think I am going to focus on making the stubs for PoiCenDai closer to the JSP side for a couple of reasons... First off, I have just been dealing with the JSP end of things so it will be an easy bridge, second is that I am not sure of the service endpoints and will need to fiddle with JAXB and CXF and it would be good to know where the resulting objects are going to go.

Of course this is all liable to change as assumptions will probably be made and then be proven wrong or not feasible. Another wacky day in coding big enterprise type things.