Zip3's now much better.

Well, the zip3's are now all showing up. But, as you can see from the wonderful comment that Jim left, , zip3's are so-so geographical locators and spurious populational references. As Jim pointed out, having one contiguous zip3 for 'Manhattan' pretty much makes epedemiology by zip3 useless in New York City. Then again I don't think we're using Zip3's for epedepiology, they are "things which are bigger than zip5s but smaller than states".

But this all brings up a good point: Our system is going to have to be all sorts of flexible. This is because we are dealing with GeoData, and in addition to GeoData changing all the time (zipcodes move, census numbers are updated), everyone will want to use a different set.

I don't think anyone will ever agree on a good way to geographically handle reporting systems like RODS or Poicondai, and the requirements will be completely different depending on whether things are being veiwed based on geography or population density, so I feel like the easiest thing we can do is allow for our systems to easily start using whatever new-fangled (or old-fangled) visualization technique is preferred at the time by whomever wants to use our system.

I feel like Gmap-Polygon is a good step in that direction. It basically is a way to put polygons on the map for whatever region you want to draw, so as long as you have the polygons put into the database before hand, and you know how you want to shade them, you should be able to use the software easily. This is of course assuming that you wanted to put it in a secure portal and didn't just want to expose KML (because for drawing polygons with nifty shading and effects, KML is a bit more straightforward).

I feel like the other thing that PHGrid products will need to start focusing on are ways to securely associate data, because a lot of people will want to focus on things like the Census Tracks that Jim mentioned, and no-one will know what census track they live in when they go to a hospital, and pulling up address data for a count item is going to be a very big no-no for things outside the secure network. I wonder if one of the applications of the Natural Language Processor can be backfilling the AMDS regional info with census track data and the like.

Demos are pretty

Sorry for the lack of updates on my part. I was spending most of the week improving the already nifty Poicondai demo to have variable y-axises and start grouping by week if queries over 180 days (about 6 months) are chosen.

You can check it out by going to http://ncphi.phgrid.net:8080/poicondai-web/poicondaiMap.jsp

The other thing I did was get ogsadai running on secure-tomcat and verified that rodsadai could connect to it. Many many many thanks to Felicia for helping me with that yesterday. She had already found out all the crazy things that had to be done to get tomcat working and was able to help me get a similar setup working in about a half hour.

Next up is zipcodes. I will need to convert the zipcodes into a geolocational database for poicondai, and then I will be updating poicondai-web to select zipcodes, updating rodsadai-web to use zipcode polygons (which I hope will turn out pretty cool), all while hopefully implementing some new filtering so I can pull all the different configuration options into one file.