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.
Showing posts with label Natural Language Processes. Show all posts
Showing posts with label Natural Language Processes. Show all posts
Tuesday, January 13, 2009
Wednesday, July 30, 2008
NLP & Ramp-Up Progressing
I completed the installation of Ubuntu on my laptop last night and I have installed Globus locally. I installed the Simple CA client to keep everything self contained. I will continue to install the other components in the installation guide before the end of the week.
I have access to both the GridMedLee and Zip Code project on my local box. I will begin writing the GridMedLee client in the morning. Both of the above projects were created using the Introduce tool which produces atuo-generated code client code. My intentions are producing a client outside of the Introduce framework.
I have access to both the GridMedLee and Zip Code project on my local box. I will begin writing the GridMedLee client in the morning. Both of the above projects were created using the Introduce tool which produces atuo-generated code client code. My intentions are producing a client outside of the Introduce framework.
Labels:
CoE PoC,
GlobUS,
Natural Language Processes,
Programming
Thursday, May 1, 2008
That's one JSP down
This morning was wonderful, Alastair of the OGSA-DAI project helped me get the log4j configured properly in tomcat, and then I was able to view logs and discover the nature of the errors. With that, I got the first JSP running (a simple extension of the existing SQLClient example class). The rest of today was spent modifying the JSP and the attached classes to be more HTML friendly, and now I am trying to make the inputs dynamic (so you can type in the query you want to try and select the resource you are polling and select the URL of the box you wish to query)
After dynamic inputs, I will want to start the dynamic population of inputs... so that the client queries the grid to figure out the OD resources at a given node... and on a separate front, I will start looking at trying to dynamically select from multiple sources at once.
Another thing that was discussed today was how to implement distributed Natural Language Processing using Globus and it's tools. There was lots of discussions of Apache AXIS and OPAL and which might be a better "wrap this interface and make a set of WS code ready to deploy to a container" tool... One of the notable quotes brought up during this was that "Web services are pretty much the Rube Goldberg devices of the Internet."
After dynamic inputs, I will want to start the dynamic population of inputs... so that the client queries the grid to figure out the OD resources at a given node... and on a separate front, I will start looking at trying to dynamically select from multiple sources at once.
Another thing that was discussed today was how to implement distributed Natural Language Processing using Globus and it's tools. There was lots of discussions of Apache AXIS and OPAL and which might be a better "wrap this interface and make a set of WS code ready to deploy to a container" tool... One of the notable quotes brought up during this was that "Web services are pretty much the Rube Goldberg devices of the Internet."
Labels:
GlobUS,
JSP,
Natural Language Processes,
OGSA-DAI
Subscribe to:
Posts (Atom)