Google Maps and privacy

I get asked a lot about how Google Maps works with our data (like the grid viewer, quicksilver, rodsa-dai, etc). Specifically, concerns about privacy and security of sending your data to Google.

There is a popular misconception about Google Maps and how it handles data. Way back in the olden days (~2006) the easiest way to use google maps was to hand google a KML file and google would draw it on their maps site. This was convenient but involved passing your data points to google within a KML file.

PHGrid does NOT do this. We use the Google Maps API which sends no data on to google maps other than requests for map images. No counts or conditions or calls or any data is passed to the google servers. All that stays on PHGrid web servers and users' web browsers. All of the polygons and pins are drawn using Javascript without passing data points back to maps.google.com.

So from a privacy concern, Google can tell that a random user is requesting a map of the state of georgia (and scrolling and zooming) but will not know the polygons drawn, the pins placed, the counts that affect the colors or any of the actual AMDS data.

So, Poicondai is out there and pretty.

I have been making several modifications to the Poicondai-Web demonstration.

You could go to the service registry of the PH-Grid wiki to find the link, but I am going to go ahead and post it here:

http://ncphi.phgrid.net:8080/poicondai-web/

Please go ahead and poke it, and especially the poicondaiMap.jsp page. Any searches you do will help build the cache and improve the responsiveness.

Also, please email me any bugs you may find, so that I might start thwacking accordingly.

Cheers!

RODS, poicondai-web, and GIS.

Yesterday I got the filtering completed... today I started answering the question "so how do you get google maps to show polygons for zip codes" and I learned quite a few things.

1. Lots of other people have done this before me, as there are all sorts of cool websites (with code access for pay) that have the overlays for zip codes and phone area codes on top of a google map.
   
2. Lots of these sites seem to work by building a KML that google can read.
   
3. RODS is one of these sites, and at least that code is free.

What I am trying to do will use KML as a last resort. KML generation means you have to stick a KML document at some public URL and tell google maps to find it, and the CDC end of the grid is all sorts of locked down... and as far as I can tell, Google Maps regrettably does not have a "send me a string of KML" function.

But, there are ways to generate polygons and overlays with just the javascript commands, just like there are ways to drop points on a map with javascript commands, it's just a matter of teasing out coordinates for the borders of the polygons, and Jeremy helped me discover the appropriate PostGIS and postgres tools that are supposed to let me get a zip-code/border database... and he has shown me the way to the RODS code that makes the appropriate queries to get the coordinates that are usually sent to KML. I'll just have to make it so they are sent to javascript arrays instead.

It'll be a bit kludgey, and will probably need some caching, but it should work, and then you know the only thing you need to see to deploy the POIConDai web visualization is access to the service and the appropriate GIS database.

Also, tomorrow will probably be spent focusing on just getting the zip code centroids working and teasing the data out of the NPDS service appropriately. But it's nice to have some part of my mind working on how to turn those dots into polygons for the time being.

Otherwise, we had a meeting with the ESRI/DGI-net guys. Their browser is mega-posh.

poicondai moves forward

Yesterday and today, I managed to do a few updates to poicondai, and basically have it to the point where it has a drop-down for ClinicalEffect to filter as needed.

Tomorrow, I will be building up the GIS databases to support making polygons, and hopefully I will be able to get polygonal data on a google map sometime tomorrow or Thursday.

Otherwise, we had a meeting with someone who is a bit better at web design than me, so hopefully the demos will be a lot prettier.

And finally, we got the Dallas problem solved, looked like there was a box in need of a restart and some bottlenecks that needed to be sorted out.

Poicondai is getting some more love

So, after I just got to the base of how to get Introduce to do things (with many, many thanks to Felicia) despite a whole lot of demos going on... I am now given charge to give the Poicondai-web app some more nift (as it can stand to be more nifty).

Thus, I have written down the next steps of RODS-GDBC in the RODS-GDBC wiki-entry. And now I shall go into the next set of requriements for Poicondai-web.

1. Use the basic test of NPDS-Web to make sure the condition list operates properly
2. If so, code a drop down of the possible choices, and discover which choices return higher results and indicate them in some way (star, different color)
3. Get a spatial series and use a pinpointed google map.
4. Make that a shaded polygonal google map
5. Make histograms when you click on the zip
6. Work out one histogram for multiple zips.

Numbers 4, 5 and 6 get more optional as time becomes an issue. Also, someone with better web design skills than me is going to be looking at using some pretty RSS and making things a bit shinier and appealing than my usual non-centered engineer-interface JSP.

I am actually sort of excited, sprucing up a demo means that people liked what we did and are anxious to see it do more. I'll try my best to not keep them waiting.

We've got dots, and they are indicating levels.

After a lot of tinkering with the google maps API and a lot of things that theoretically should work but didn't... I managed to get dots showing up on a google map and color-code them based on the level of incidents indicated by the query. They also load a bit slowly because of how I had to encode the data series, but it works, and that is better than before. I also have lots of ideas of how to make things faster and prettier given time thanks to Alastair and Mario of Ogsa-Dai, who helped me kick around ideas.

Next steps are to bisect the databases and put them on different database servers... wire up such nifty bisections into the demo app, and if time allows, start integrating the results.

I am happy. I got dots.

Building Demos

I got some very cool news from Dr. Espino today, that he had gotten RODSAdai building and happy on his end, and will probably be able to integrate all the code within a week. Furthermore, he added much better logging code (log4j complete with properties files), some null checking, and some defaults. I have successfully updated everything and adjusted to fit my own environment.

On the demo end, I have discovered many things that will not work with google maps as I envisioned them. I was thinking of doing real-time geocoding of zip codes, but that would turn one javascript request to google into about 30, and there are already free databases of zipcode geospatial locations. Furthermore, I am not sure of the best way to just lay out all the data given google's finicky timeouts (thus, if your application takes a while to generate a KML file, you will need to generate the file and place it somewhere in an accessible spot and then tell google to find it there).

Considering I am not exactly working on an accessible node, I am beginning to think it might just be easier to use JSP loops to build an array and then place that array into one of googles marker manager objects. Perhaps there is a way to pass KML into a google map directly? I will probably tinker with this at home.