Drawing div circles using javascript

For the legend I had to generate circles of certain pixel sizes. To do so, I used Walter Zorn's helpful javascript graphics library.

Able to generate many pies

I got the script working to generate and manage many pies at once. The script generates 10 pies placed randomly on the map with random haplotype distributions with random (but consistent!) colors. The pies are draggable and zoomable, and the DOM node structure remains consistent with zooming.

getting the preview pane working

I spent most of this week trying to get the basic functionality of the preview pane working. The goals were to draw a map with randomly generated pie charts and colors where the pies were draggable and zoomed appropriately. I succeeded in generating this zoomable and draggable pie chart. Try it out. The page generates a pie with random slices and colors. Try dragging the pie, zooming to new levels, and try dragging again.

These are the steps that I took to build that code:

1. Draw a circle on a map.
2. Draw multiple circles on a map.
3. Make the circles draggable.
4. Draw a pie on a map.
5. Make the pie draggable.
6. Make the pie zoomable.
7. Make the pie zoomable and draggable.

I ran into various bugs along the way that made this problem really challenging. Here are some of the implementation details:

• Drawing the circles in Google Maps (GM) is actually easier than in Google Earth because you can easily calculate the pixel coordinates of the 90 vertices that comprise the circle. GM provides functions like fromDivPixelToLatLng() and fromLatLngToDivPixel() that then make switching back and forth to latlong coordinates easier, and you don't have to do all the complicated haversine computations yourself.
• Making the circles draggable was a little difficult because you have to wrap the created circle svg's within appropriate HTML div elements. This turned out to be somewhat complicated because it involved manipulating the DOM node tree that simultaneously updated our array of svg elements.
• Drawing the pies instead of circles added another layer of complexity because not only does each svg of a pie slice need to be wrapped in its own div but then all the slices of the same pie need to be wrapped together in another div that was made draggable.
  
• One bug I ran into was how to get the pie pieces to fit together seamlessly. The random numbers generated for the dimensions of each slice didn't correspond exactly with the 90 evenly spaced vertices (one vertex every 5 degrees), but some simple rounding and modulo type operations fixed that. That means that the pies are not exact representations of the input data, they may be off 5 degrees or so for each slice, but I'm guessing most humans won't be able to notice that.
• So making the new pie divs draggable wasn't a problem, but making it work with the zoom function was a bear. After zooming, the pie would either become undraggable, we'd see too many copies of the pie, and/or not all of the copies would be the same or in the correct places. There were several issues to overcome. First, I had to wipe and redraw the overlays containing the pies. Second, I had to repackage the functions so that I could save and access the random data that had been generated (i.e. the slice angle data, slice colors). Third, I had to update the location information of the pie after it was dragged. The first two tasks were not bad, but the last bug took the longest to fix.
  
• At first, I tried to get the new location info from calculating the center point of the encapsulating div. Several problems with that approach: I could get the info for the left top corner of the div, but the height and width were zero, and the div's size was not only just large enough to fit the pie (the width of the div was not equal to the diameter of the circle) as I had assumed, and finally I realized that what was returned by style.left and style.top was NOT the coordinates of the top left corner but rather the offset of the coordinates in pixels.
  
• I could use the offset in pixels to calculate the new lat and long for the center of the pie. However, to convert from pixels to latlng units I needed to use a different function that incorporated zoom level information (different zooms will have different latlng to pixel relationships). This involves declaring a GProjection variable to get the fromLatLngToPixel(latlng, zoomLevel) function. Whew! But finally, we have pies we can move and zoom.

image overlays vs. polygons idea revisited

I played around with the idea of using image overlays to create the pies vs. using polygons.

Overlays
Pros: In GE you can easily grab and move, resize, or rotate the image. This way, the user wouldn't totally be reliant on our application to manipulate the pie charts.
Cons: The images could get ugly if increased in size by too much. Also, we'd lose the ability to turn different aspects of the pies on and off (like the labels, particular haplotypes, etc.). And we wouldn't be able to change the colors of the different pie pieces without returning to the application.

Polygons
Pros: There's a lot of information retained in the file hierarchy. The user can turn various components on and off and recolor them easily. Plus, the image is likely to be crisper.
Cons: The user cannot move or resize the pies without going back to our application.

I think that having the ability to access the components of the pies (haplotypes, labels) easily outweighs the hassle of resizing and moving. To get around the hassle, our program will have to have some sort of collision detection mechanism, and some easy way to resize pies. Can we preview the map on google maps before exporting to GE? and allow the users to change things there? That may be the best work around. So I'll continue down the polygon path and leave behind image overlays.

Another thought on overlays: It would be nice to have a species distribution overlay function, where the user uploads an image file with the species distribution and can stretch it to fit the map. Also, I wonder if someone's already made overlays or paths of things of common interest, like where the ice margin was at the LGM, or if there's a repository of species distribution data.

my first pie!

I got my first pie working! It looks good. Not oblong anymore. And I figure using 360 vertices should make generating pie pieces of any size easier. I don't think it adds that much bulk to the code either, but if it's a problem we can always go down to 20 or so points.

I placed the label and pie pieces in different folders so you can click off the labels easier. Here's the KML.

finally have formula that's working to calculate locations of vertices

So, after poring over ink_polaroid's solution for what seems like forever, I finally figured out what I was doing wrong! Just a note: PHP and Excel's arguments for the atan2 function are reversed. What a headache for something so simple.

Here's the algorithm for calculating the latitude, phi2, and longitude, lambda2, of a point distance, d (in meters), away from a point with latitude, phi1, longitude, lambda1, and angle, theta (from vertical, parallel to longitude lines).

d_rad = d/6378137 (6378137 m is radius of Earth at the equator)
phi2 (in radians) = asin(sin(phi1)*cos(d_rad) + cos(phi1)*sin(d_rad)*cos(theta))
dlon = atan2(sin(theta)*sin(d_rad)*cos(phi1), cos(d_rad) - sin(phi1)*sin(phi2))
lambda2 (in radians) = Modulus(lambda1+dlon+PI, 2PI) - PI

Remember to change everything back into degrees for GE.

how about overlays instead of polygons?

Just another possibility -- how about using pie charts as overlays instead of polygons? Just another thing to explore this weekend...

oblong circles

I tried a bunch of tweaks to the formula that calculates the positions of the 20 vertices comprising the circle. Unfortunately, all of them are off enough that the circle is still oblong, and it seriously morphs depending on where on the globe the central point is. The formula that I ended up working was:

Length of a degree of longitude = cos (latitude) * 111.325 kilometers

from this source.

So my conclusion is that this formula must not be accurate enough. I spent most of the rest of the day yesterday searching various google earth forums, and happened on this post. It seems to calculate the vertices using the haversine formula and great circle distances. I think this is the next method to explore.