Hello everyone.
Poicondai-web now has zipcode polygons. You can see them here
Also, I have updated the poicondai-web service registry page with some more information about how to download and install the poicondai-web, poicondai-util, poicondai-loader, and NPDS-WS-Client. That is here
Next up is putting those polygons into Rodsadai... but that will be after the holidays.
Have a happy Thanksgiving everyone!
Wednesday, November 26, 2008
Thursday, November 20, 2008
I have polygons, but not all the zips that might be sought out.
I have polygons, and have shown that I can get all the polygons possible showing up in Colorado.... but there is a problem...
The list of zipcodes I have and the list of polygons for the zipcodes I have show some discrepancies... And it all stems from the fact that zipcodes can change. Thus, there are several areas that are blank in my "map of Colorado" because they have to do with zipcodes that might have split recently or were otherwise not in the Geolocation data I have been given.
That doesn't mean that the NPDS doesn't have a few results for them.
Thus, I am in a bit of a quandary. I guess the best thing I can do at this point is have a little table at the bottom of the map that says "zipcode ##### was not in the polygon database." Because even if we changed the polygons to fit with old zipcodes it means that there would have to be polygon overlaps and it would get very confusing.
Otherwise, I imagine poicondai with zipcode capability (at least the ones we have polygons-for) will be ready for testing sometime tomorrow.
The list of zipcodes I have and the list of polygons for the zipcodes I have show some discrepancies... And it all stems from the fact that zipcodes can change. Thus, there are several areas that are blank in my "map of Colorado" because they have to do with zipcodes that might have split recently or were otherwise not in the Geolocation data I have been given.
That doesn't mean that the NPDS doesn't have a few results for them.
Thus, I am in a bit of a quandary. I guess the best thing I can do at this point is have a little table at the bottom of the map that says "zipcode ##### was not in the polygon database." Because even if we changed the polygons to fit with old zipcodes it means that there would have to be polygon overlaps and it would get very confusing.
Otherwise, I imagine poicondai with zipcode capability (at least the ones we have polygons-for) will be ready for testing sometime tomorrow.
Labels:
GBC PoC,
PoiConDAI,
zipcode polygons
Grid Enabling Existing/Legacy Applications With gRAVI
I recently wrapped SatSCan in a grid service using gRAVI and gRAVI treated me
well. gRAVI can be downloaded as an Introduce plugin and it is designed to wrap
a grid service around an executable. Your job can then be treated as GRAM job
which is great because the status of the job is then represented via GRAM (staging, running, finished, ...). Also, by default gRAVI stages your files in for you and transfers your results back to you via byte array. I think in gRAVI 1.4 will support the following transfer mechanisms: gridFTP, byte array, caGrid Transfer.
If you need to grid enable an existing/legacy application I highly recommend gRAVI. It will save you time.
Anyway, I just started my second iteration on grid enabling SatSCan and I have some work to do on the client plus the Cloud is on the horizon for this service. I better get back work:)
Here is a link to gRAVI: http://dev.globus.org/wiki/Incubator/gRAVI
World Wide Grid
All of that dark fiber and computing power has to be used for more than just YouTube videos. The EU has invested 2.5m Euros into a project that will make worldwide Grid computing more accessible. http://cordis.europa.eu/ictresults/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/90191
Wednesday, November 19, 2008
Zipcode Polygons are working in testing.
So I have zipcode polygons enabled.... I also have modified poicondai-web to use maven filters.
Note to self: the test resources are different objects in the pom.xml than regular resources.. thus, if you need to enable filtering on the test resources in a maven2 project, you will need to create a section for it...
Tomorrow, I will modify the main pages to get zipcodes encoding and popping up search lists... and then I think I will be examining rearchitecting poicondai-web to have a much simpler structure with a class returning all the polygon javascript instead of doing it in the JSP.
Then, it'll be polygons for Rodsadai.
Note to self: the test resources are different objects in the pom.xml than regular resources.. thus, if you need to enable filtering on the test resources in a maven2 project, you will need to create a
Tomorrow, I will modify the main pages to get zipcodes encoding and popping up search lists... and then I think I will be examining rearchitecting poicondai-web to have a much simpler structure with a class returning all the polygon javascript instead of doing it in the JSP.
Then, it'll be polygons for Rodsadai.
Labels:
GBC PoC,
PoiConDAI,
polygons,
zipcode polygons
Tuesday, November 18, 2008
AMDS Sample Structure
So Jeremy and I have been tossing some ideas back about an initial draft for the AMDS data structures. Based on discussions led by Tom Savel on what fields should be included in the AMDS, we're going to start testing development using a basic AMDS that includes:
Felicia is starting to think about converting the RODS-HDS service (developed to meet this feature request) to RODS-AMDS to meet the draft xml structures. These xml structures are very lightweight and we will modify them as the AMDS data structure undergoes changes based on scientific comment.
The next step is to add the sample xml and schemas to the wiki so we can start getting comments in. Based on comments, we will start to plan services that provide BioSense VA and DoD sample data using the AMDS structure so that it can be combined with RODS data (and eventually EARS, ESSENCE, other systems).
- Date
- Patient Zip3
- Syndrome
- Syndrome Classifier (i.e. which classifier was used to assess the syndrome)(e.g. BioSense, EARS, RODS, ESSENCE, etc.)
- Count
- Denominator (i.e.total count of all syndromes for that zip3 on that date)
Felicia is starting to think about converting the RODS-HDS service (developed to meet this feature request) to RODS-AMDS to meet the draft xml structures. These xml structures are very lightweight and we will modify them as the AMDS data structure undergoes changes based on scientific comment.
The next step is to add the sample xml and schemas to the wiki so we can start getting comments in. Based on comments, we will start to plan services that provide BioSense VA and DoD sample data using the AMDS structure so that it can be combined with RODS data (and eventually EARS, ESSENCE, other systems).
Updated DRN Design drafts
I updated the DRN Design Drafts wiki page with a data flow diagram to show the flow of detailed data --> aggregate data --> combined aggregate data based on some feedback from Roy Pardee, Ross Lazarus and Jeff Brown.
Zipcodes polygons in the database
So, I have updated the poicondai-loader project and the poicondai-util project and now we have zipcode polygons in the polygon database.
Also, the deploy of tomcat to the staging node went swimmingly. Dan switched the tomcat server over to port 8443, and rodsadai and poicondai worked like nothing had changed.
So, tomorrow is starting to do some testing with the zipcode polygons, and then updating the map application to have zipcode polygons in addition to the county polygons.
Also, the deploy of tomcat to the staging node went swimmingly. Dan switched the tomcat server over to port 8443, and rodsadai and poicondai worked like nothing had changed.
So, tomorrow is starting to do some testing with the zipcode polygons, and then updating the map application to have zipcode polygons in addition to the county polygons.
Labels:
GBC PoC,
PoiConDAI,
RODSAdai,
zipcode polygons
Another Distributed Aggregated Query Project (SHRINE)
The Harvard Catalyst's Informatics Program has developed technology in lock step with regulatory and ethical requirements to allow authorized investigators to acquire robust sample sizes across all Harvard-affiliated healthcare institutions. We call this querying system SHRINE (Shared Health Research Information Network). As shown in the diagrams below, there is no central database but rather the SHRINE queries are distributed across each of the participating institutional databases. In this way, each institution maintains autonomy, control, and monitoring of all transactions on behalf of its patients.
Consumer Health Informatics and the Grid?
I ran across this article this morning. It's about a new program using Google Health in association with Medicare programs in Arizona and Utah. Conceptually, given the Medicare bent, this may be rich information for chronic disease interventions and surveillance. In terms of services, I could see decision support / alerts. Are there others?
http://www.azcentral.com/business/articles/2008/11/13/20081113biz-medicare1113.html
(edited 2008.11.18 by BAL to add link)
http://www.azcentral.com/business/articles/2008/11/13/20081113biz-medicare1113.html
(edited 2008.11.18 by BAL to add link)
Subscribe to:
Posts (Atom)