PhyloGeoViz

fixed a bug in the haplotype groups

2008-01-14T21:15:00.000-05:00

Fixed a bug that was causing the haplotype data in the pop_hap array to sort incorrectly. Basically there was an extra for loop in there that was causing the pop_hap array to be jumbled an extra X times. We're now up to version 2.3.1.

missing table in IE

2007-08-27T13:43:00.001-04:00

Help! I can't figure out why this table won't show up in Internet Explorer (v. 7, in Windows). The table (id="popsizelegendtable") is viewable in Firefox but totally disappears in IE. I have no idea what's going on. Here's the unprocessed source. Is it a CSS style issue? Or is some of my javascript overwriting some styles? The nodes and data are still there in the HTML tree, but it just isn't viewable. I feel like I've turned every display to block and zoom to 1 and am out of ideas.

Works in Firefox and IE (almost)

2007-08-27T13:39:00.000-04:00

Version 2.3 is now up! Now it works in Firefox on Windows, Linux, and Mac, and has almost all functionality in IE in Windows and Mac. The only thing missing it not being able to draw the sample size legend in IE.

Aha! Getting google to return svg's instead of img's solved

2007-08-27T11:48:00.001-04:00

So thanks to Mike William's post to the Google Maps API Google Group, I can get GPolygon to return svg's instead of img's in Firefox in Linux. Yay!

Basically, you have to set these two parameters, _mSvgEnabled and _mSvgForced to true in order to force Google to return SVG's. Here's the code snippet that made everything better:

function load() {
if (GBrowserIsCompatible()) {
// Initialize
if(document.implementation.hasFeature(
"http://www.w3.org/TR/SVG11/feature#SVG","1.1")){
_mSvgEnabled = true;
_mSvgForced = true;
}

VML - link to reference

2007-08-24T10:50:00.000-04:00

A useful link to VML documentation:

w3 VML specifications

Conflicts between jQuery and Prototype objects in IE

2007-08-24T10:43:00.000-04:00

I'm not sure that I have this problem correctly diagnosed, but I've been noticing a lot of errors in IE when I have lines of code that combine jQuery objects with Prototype functions. I guess this means that I've been sloppy with my JS and Firefox has been letting me get away with it! Here's an example of code that works in Firefox, but not IE:

var block = jQuery(".widgetBody", $(elementid))[0];
var blockstatus = block.getStyle('display');

It seems like the problem is mixing the jQuery object, block, with the prototype function, getStyle(). The error is removed when I replace the second line with a call to a jQuery function instead:

var blockstatus = jQuery(block).css("display");

I guess it makes sense that combining jQuery and Prototype code is a bad idea. I was using Prototype to begin with then started using more and more jQuery, and never went back to clean out all the Prototype. Heck there's even Prototype in the line with the jQuery search! Anyways...laziness is costing me now.

Addition of VML line critical to getting things working in IE

2007-08-24T09:35:00.000-04:00

I can't believe I missed this until now. To get the polylines and, thus, polygons to render correctly in IE, you have to include a reference to the vml namespace. The top of your document should look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml">

See the documentation on XHTML for slightly more info.

Internet Explorer -- pain in the ass

2007-08-23T15:41:00.000-04:00

I've started debugging the program in Internet Explorer (v. 7.0.5730.11) on a Windows machine. I've been using Firebug Lite and the IE developer toolbar to help debug. Even put together, neither of these is remotely useful compared to the awesomeness of Firebug in Firefox. Anyone out there have a recommendation for anything better for IE development and debugging?

XRay is another interesting CSS viewer tool that works in any browser.

Fixing svg/img bugs

2007-08-23T10:27:00.000-04:00

So I got a bug report that said that the site didn't work in Firefox in Linux. Only one wedge was being drawn. Turns out that for some reason the call to GPolygon that usually produces svg's produces 'img' elements instead. This caused a bunch of problems. Now I've fixed it so that I check if img's or svg's are produced, then modify the event handling of those objects. I suspect that this img/svg problem may be at the heart of the app's bad behavior in Internet Explorer and Safari as well. But there are more bugs to take care of there... Just a note: Gmaps in Firefox in Windows and Mac DOES produce svgs.

By producing img's instead of svg's certain features of the site become impractical to implement. The biggest problem is that the img's must be completely redrawn each time there's a change. With svg's I can easily change the style (fill color, stroke width, etc.) of the element without having to redraw the graphic. The drawing of the pies is time consuming, so with img's I've disabled the dynamic updating of the pie wedge colors. Now the user must click the 'ok' button to submit their new color requests.

Note: I'm not sure who's 'fault' it is for not being able to use svg's on Firefox in Linux. The documentation for Firefox states that svg support is now built in to the latest release, so maybe it's Google Map API's fault for returning the wrong img datatypes when it should return svg's. In any case, img's are what's being rendered on the page.

Development environment in Linux

2007-08-23T10:23:00.000-04:00

So getting my development environment set up in linux was no small task. I'm using Fedora 6. Here were some of the obstacles:

1) The distribution's version of Firefox doesn't come compiled with the necessary debug flags for Firebug to work properly. I downloaded a new version of Firefox directly from the website and that seemed to have solved most of the debug problems. I've heard that you may need to download the source and compile it by hand with some special flags, but luckily the downloaded tarball worked for me.

2) The php-json package was missing from my installation of php. A simple yum install fixed that problem.

Last weekly update

2007-08-20T16:28:00.001-04:00

I've just uploaded my code that I'll be evaluated for Summer of Code experience (version 2.2.2). Whew! I really enjoyed the summer and learned a lot. There still are many more features I'd like to add, but I feel pretty happy about the product at this stage.

Thanks, everyone!

Phyloinformatics Summer of Code Meetup at NESCent

2007-08-20T16:11:00.000-04:00

At the end of last week the NESCent SoCoders all met up in Durham, NC for a wrap up conference. It was really neat to see what others had been doing all summer long. The diversity of projects was to be expected, though there were some common threads between us.

One message that was hammered home to me was the need for file standards in evolutionary biology. The amount of time spent massaging your data into different formats to interface with interesting programs is many times prohibitive to actually using the programs. I was struck by all the development going on with NEXUS (ex: Nexplorer, NEXML, and libraries for NEXUS) in particular, and I feel like I need to jump on this bandwagon too! I was quick to realize that I'm part of the problem in that PhyloGeoViz currently doesn't accept NEXUS (or anything else for that matter besides my own special format). Well, being able to work with NEXUS files is now on the top of my list of priorities.

Another common theme of the meeting was the visualization of tree data. Multiple projects were coming at this problem using different languages and in different contexts.

A great meeting! I had a lot of fun hearing other students' and mentors' experiences. Hope to run into you again soon!

Licensing

2007-08-20T11:59:00.000-04:00

I decided to use the GNU GPL. It seemed the most broad.

I'm not sure if I did this correctly, but my Google SVN project repository contains other people's scripts (like Prototype, YUI Color Picker, jQuery, etc.) that have their own licenses, etc. All the scripts I used are open source libraries, but I'm not sure if including them in my own repository is ok. Should I have just told the user to download them themselves or is it ok to package everything together like I've done? In any case, I think it's ok to put everything in one place.

New features added

2007-08-20T11:54:00.001-04:00

Last week I tried to code up as many of the features as possible prior to the meet-up at NESCent. Here are some I managed to add by the end of this past weekend:

Expandable/collapsible menu widgets for the legend.
Outline pie wedges option.
Enlarge/reduce map window size.

I also got all the pages prettied-up with the same css styles, which I think made a huge difference to the look and usability of the site. Thanks, Jack for helping me feel my way around CSS this week!

Newest version is up. Version 2.2.2.

Icons

2007-08-20T11:49:00.000-04:00

Here's a nice icon set that I found. Very good looking. But it didn't have the +/- icons (for expand/collapse a tree) that I needed.

Silk icons

I did, however, use this nifty site that generates pretty ajax loading icons (animated gifs) for you.

ajaxload.info

Uploading to google repository

2007-08-20T11:47:00.001-04:00

I finally got my local source code uploaded into Google's subversion repository. It was a bit of a chore to figure out how. And I couldn't figure out how to keep all my own repository history alive. Ah well.

Weekly update

2007-08-13T11:57:00.000-04:00

I've spent most of the week tying my pages together. Now the user can input haplotype group data as well as the basic input data. Also, the edit data page now integrates with the rest of the site. The color picker that dynamically updates the pie wedge colors has been tested as well.

Things to do this week:

Clean up code for repository.
Include comments on the license, etc.
Get code into repository.
Write documentation and user instructions.
Edit CSS and make site look prettier.
Prepare presentation for NESCent meet-up at the end of the week.

Version 2.0 up and running

2007-08-13T11:51:00.000-04:00

I've uploaded my latest version. Still need to fiddle with css to make it look nice, but the basic functionality is there. New features:

When changing color the pie wedges update with new colors in real time.
An edit data page, where the user can include/exclude populations or haplotypes and edit data fields.
Users can now group haplotypes by specifying haplotype groups.

Stuck on image creation

2007-08-13T10:07:00.000-04:00

I'm trying to output the legend (of haplotype colors and of sample sizes) to some sort of image format (*.png for example). However, I'm quickly realizing that I'm in over my head. Anyone out there know of any javascript libraries that can help me?

So I'm putting this on the back-burner for now. I guess if you want to save the legend info, your simplest bet is to do a print-screen + crop.

How to auto-submit a form

2007-08-07T21:03:00.000-04:00

Sometimes it's useful to pass data to a hidden page that processes the data then passes the new data to another page. To pass the data through forms, use javascript. Set a body onload function with $("form_name").submit() to submit the form when the page finishes loading.

Example:


<?php
  ....data processing code here
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"\n
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
    <script type="text/javascript" src="javascripts/prototype.js"></script>
  </head>
  <body onload="$('newdata').submit()">
    <form id="newdata" name="newdata" method="post" action="newviewer.php">
      <input type="hidden" id="data1" name="data1" value="x1">
    </form>
  </body>
</html>

JSON, php, and html forms

2007-08-07T20:54:00.001-04:00

So I've been working on a data processing page that is hidden from the user, takes form data from an input page, processes the data, encodes the data using json in a new form, then auto submits the form to a new page. Here are a few helpful functions that got it working properly:

1. The json_encode() function in php doesn't escape some html special characters like quotes. It's helpful to wrap it with the function htmlspecialchars() so that it plays nice with your html.

2. php line breaks are '\r'. I had inadvertently included some line breaks in my string variables. To fix that problem use the trim() function.

Weekly update

2007-08-06T01:03:00.000-04:00

This week I've spent hacking away at the data management page. I've got all (cross you fingers) the bugs smoothed out from transferring the changed data from the data management page to the viewer page. A new feature of note is that the program now sorts the haplotypes by groups and the user can color all haplotypes in a group at once. (Note, I haven't uploaded the newest version to the website yet, sorry).

Features added this week:

Can include/exclude haplotypes and populations.
Can edit data.
Can specify haplotype groups.
Can color by haplotype group.
Changing colors in the colorpicker now changes the associated pie wedge colors in real time.

Next week:

Meet with David about the remaining goals for the project, and project timeline.
Update the export function to allow grouping by haplotype groups, etc.
Tie the data management page to the input data page.
Update website with latest release.
Research copyright laws and permissions concerning the maps.

onChange handler for the colorpicker

2007-08-06T00:37:00.000-04:00

Knallgrau's color picker has been a really useful library, but it took a bit to figure out syntax for the onchange handler. Each colorbox shares the same colorpicker, so I was having trouble deciphering which of the DOM elements was the calling element, so I set an 'onclick' handler on the 'ok' button then had a big loop through all the possible elements to see which one changed. Besides being ugly, the user doesn't have to click on the 'ok' button to exit the colorpicker, so this implementation fails to register a lot of events.

Turns out I was going about this all the wrong way. Knallgrau has an 'onUpdate' attribute that you can set. Here's the syntax when initializing the colorpicker:

new Control.ColorPicker("inputid", { IMAGE_BASE : "javascripts/colorpicker/img/", "swatch" : "buttonid", "onUpdate" : changeColor });

where 'inputid' is the id of the <input> element, 'buttonid' is the id of the <button> element, and 'changeColor' is the function called when the color is updated.

In the changeColor function, this.field gives you the input element. Example:

function changeColor ()
{
console.log (this.field); //prints <input type="hidden" id="hapcolor1" name="hapcolor1" value="B71919"/>
console.log (this.field.id); //prints "inputid"
}

jQuery!

2007-08-06T00:34:00.001-04:00

So I've been trying to update all of the pie wedge colors in real time as the color picker runs. To do so I have to have a quick and efficient way of grabbing, traversing, and setting specific DOM elements. jQuery, this fabulous javascript library does all that and more! It's super fast. But the documentation is a little harder to understand than for prototype.

another bug to fix

2007-08-01T12:34:00.001-04:00

Fart! If you click away from the default map type on the viewer screen (say go from 'satellite' to 'map') you lose the ability to drag the pies and color them. It's bizarre, but if you resize the pies you get back some of the draggability and can recolor them....

Weekly update

2007-07-31T15:17:00.001-04:00

Most of this week has been spent on the include/exclude data and data management feature. It's not quite complete yet. I've run into a lot of difficulty getting the event handlers to update the appropriate javascript variables.

This week I:
Updated the website with a working version (including color picker).
Worked on getting data manager working.

Next week's plan:
Finish data management page.
Start legend/logo export feature.
Look into copyright permissions info from google.

Updated public version

2007-07-26T16:11:00.000-04:00

Version 1.02 is up. Now users can edit their colors and their data input is simpler.

Removed need to input pop number and hap number

2007-07-26T16:10:00.001-04:00

I simplified the input format requirements. The user no longer has to input the number of populations and haplotypes on the first line.

Weekly update

2007-07-22T22:49:00.000-04:00

This week I:
1. Got my code into SVN. I feel safer already.
2. Made the input protocol more flexible.
3. Allow users to set own population names.
4. Allow users to change haplotype colors.
5. Updated website.

Next week I will:
1. Update website with new version.
2. Get code into repository.
3. Add grouping of haplotypes feature.
4. Add include/exclude data screen.

Color picker working!!!

2007-07-22T22:41:00.000-04:00

After some heartache, I finally got the colorpicker working. Now the user can change the colors for each of the haplotypes on the preview pane. I used Knallgrau's color picker as a base for this.

I ran into many problems trying to get an event handler to fire correctly. I tried at first to have the pie colors update simultaneously with the color picker's. I wanted to associate an event handler with changes to the input field's value (string of HTML color type), but for some reason the value is hidden from the event handler. Eventually, I tied an event handler to clicking the 'ok' button of the color picker. There is only one color picker display for all of the haplotypes though, so I had to loop through them all to find the one that had changed. Then we loop through the corresponding pie slice and reset their fill color. Remarkably, this is super fast.

Setting the default map type in Google Maps

2007-07-22T17:58:00.000-04:00

So I ran into a silly bug trying to set the default map type (default, satellite, or hybrid) on a google map. Basically I kept getting an error and the map wouldn't load even though I triple checked the constant's name, etc. Turns out that the order that you call setMap commands matters. Turns out that the setCenter() command must be given first before any other alterations to the map can be done. Here's the code for setting the map to satellite view by default:

map.setCenter(new GLatLng(36.739067, -77.905517), 5);
var givenmaptypes = map.getMapTypes();
map.setMapType(givenmaptypes[1]);

I think you can set the maptype within the setCenter function call as well. This Google Maps API thread was useful as well.

Can specify own names of populations

2007-07-17T17:41:00.000-04:00

Added ability of user to set their own population names. (version 1.01).

Updated website, fixed extra whitespace bug, uploaded new version 1.0

2007-07-17T16:57:00.000-04:00

Fleshed out the website with a bit more content. Hopefully made the instructions easier to follow.

Fixed the whitespace bug in the input form. Now the program doesn't crash with beginning or trailing whitespace and accepts data delimited both by tabs and/or spaces.

Symbolic links in UNIX

2007-07-17T16:53:00.000-04:00

Just a note to self here:

To create a symbolic link use the following command:
ln -s [source file or directory] [target name]

Note: I can't figure out how to overwrite sym-links to point to new things. It's easiest to delete the old link, then write the new one.

Escape Characters link

2007-07-17T15:24:00.001-04:00

Note to self: helpful escape character link:

http://www.digitalmediaminute.com/reference/entity/index.php

bugs fixed -- comment console.logs out

2007-07-17T15:01:00.000-04:00

So I was running into the problem that the program worked fine on my machine but was puking on David's. The problem turned out to be how I was debugging my programs. I've been outputting debugging info to a console log readable in the Firebug program. If you don't have Firebug installed, the console functions are not understandable and the browser barfs. So after commenting out all my console logs, the problem went away.

I also noticed the bug that if you moved a pie and zoomed the map, the pies would not be in the right location. Turns out that I had been updating the population centers twice (once on drag, then again on zoom with the same move state), so was getting erroneous placement info. Once again, turned out to be an easy fix. Just commented out the second population updater in the zoom event handler.

Does NOT work in Internet Explorer

2007-07-17T14:59:00.000-04:00

PhyloGeoViz does NOT work in IE. But it does work in Firefox. Have no idea why it doesn't work in IE. This will be a bear to work out I think. I don't know if it's worth it. Any arguments why I should or should not take the time to fix it?

slow run time

2007-07-17T14:57:00.000-04:00

One thing I noticed when running PhyloGeoViz with my full dataset (~85 pops and ~40 haplotypes) was that the pie generation is pretty slow. I'll have to look to ways to speed it up. In the meantime, I need to put up some sort of disclaimer to the user.

Weekly update

2007-07-15T16:35:00.000-04:00

Sorry for the lack of posts, I was away at the Botany 2007 conference in Chicago. Things went great at the conference. I managed to get the PhyloGeoViz skeleton mostly working prior to the conference and was able to actually input my own data into the program! It was a great moment. I then created most of my talk's slides based on this output. I pitched the project and NESCent's Phyloinformatics Summer of Code and Google's Summer of Code programs at the end of my talk. Several people approached me afterwards, and they seemed very interested in participating next year! So hopefully I was able to do some recruiting.

On the coding front, I fixed a bad bug that was causing the program to barf in versions of Firefox without the debugger plugin. Unfortunately, the code still doesn't work in Internet Explorer. I also fixed a bug relating to dragging and zooming pies.

To do for this week:

Catch up on the project blog and chronicle what changes I've made to the code and my bug fixes.
Write function that will output the legend as overlay data in the exported kml.
Write function that can change the boundaries of the bins for the different pie sizes.
Write feature so that user can choose whether all the pies are the same size or have relative sizes.
Write a color picker function for changing the haplotype colors.

Bug fixed

2007-07-02T11:30:00.001-04:00

Turns out php was trying to interpret the xml header declaration as php. Adding an echo statement cleared out this bug.

Thanks, Jack for pointing this out!

Weekly plan

2007-07-02T11:30:00.000-04:00

This week is a bit frantic because I leave for the Botany conference on Saturday. I've been making a big push to have PhyloGeoViz ready for an alpha release and debut there. Here's my to do list for this week:

Transfer homepage style to the other app pages so the look is consistent.
Figure out export.php bug on server so that it will run!
Write function that will output the legend as overlay data in the exported kml.
Write function that can change the boundaries of the bins for the different pie sizes.
Write feature so that user can choose whether all the pies are the same size or have relative sizes.
Write a color picker function for changing the haplotype colors.
Import and manipulate my own data to create slide for talk!!!

Beautiful site design -- Thanks, Jack!

2007-07-02T11:16:00.001-04:00

Another project this weekend was to create a nicer looking home for the app on the web. The main page for the project will be at http://phylogeoviz.org/. Jack helped me out with some CSS stuff and put together a great looking page for the project. It's great having a web designer in the family! Anyways, the front page looks great and I'll get to linking it with the actual app later this week.

Thanks, Jack!

Bug! help!

2007-07-02T11:02:00.001-04:00

I've got Version 0.2 up, but unfortunately the export php script fails! Oh no! Of course, the script runs fine on my machine and environment, but on the server no longer functions. Why, oh why! Here's the error:

Parse error: syntax error, unexpected T_STRING in /home/.nayla/zeppox/oenimal.net/erica/version_0.2/export.php on line 5

I thought it might be a php version issue, so updated the php version on the server, so now we're both running php 5.2.2. But the error remains. Maybe it's a security issue with php? Anyways, any ideas??

Version 0.2 up

2007-07-02T10:52:00.000-04:00

Busy, busy week. Version 0.2 is up! I managed to get the export function working. The app can now write a kml file that can be read by Google Earth. This was a bit tricky because I had to fix several functions that weren't updating some of the variables properly after an event changed their state. In any case, that's working now.

I was also able to implement a few new features on the preview page. The pies can now be different sizes based on the population's sample size. The pies can also be increased or decreased in diameter. Also, I can now generate legend data. I'm showing the haplotype labels and their corresponding colors and the sample size to pie diameter legend data.

Drawing div circles using javascript

2007-07-02T10:49:00.000-04:00

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

Weekly update

2007-06-25T11:17:00.000-04:00

This past week focused on development of a basic data input page. I decided to use form variables (at least to start with) as the way to pass information between pages. I had to learn how to write the html to allow that plus some php to parse the passed information. I also had to figure out how to pass the variables between php and javascript to get the input data and viewer scripts I'd written to get along. Anyways, as a result I have a rudimentary input page tied to my viewer now. I, of course, still need to clean it up, add error handling, different input types, etc. But it's a start!

On the administrative side of things, I added my project blog to the Planet SoC site. Basically it's a neat aggregation of a bunch of blogs concerning many different Google Summer of Code projects. I also updated the wiki with my design doc.

To do for this week:
Get basic output page written and in synchrony with the other pages.
If time, add some functionality to the viewer (like changing colors).

Skeleton of data input working

2007-06-25T00:38:00.000-04:00

I got a skeleton of the data input working this week. Basically, the input text field is just a large textarea form field. Then I use a php script to parse out the variables, then use the javascript code I used before to generate the map pies. Data input could certainly be cleaned up, but this was just so I could learn one way of passing data from page to page (through form variables).

Able to generate many pies

2007-06-18T21:39:00.000-04:00

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.

updated project wiki to include design doc

2007-06-18T17:38:00.001-04:00

Finally got around to putting the design doc up on the wiki. I didn't get a chance to incorporate the haplotype grouping feature into the design, but I image it would mean added a table of haplotyes x group identifier on the manual data input and the data management pages. Also, I'd like to incorporate Norm's suggestions of a grayscale feature and export as .ai feature eventually too.

More features to add

2007-06-18T17:03:00.000-04:00

I was showing off the pie viewer prototype to Norm, and he had some great suggestions for features.

A black/white/grayscale option. Many journals prefer black and white figures, so it'd be great to be able to color pies with grayscale and maybe patterns.

Be able to save as an Illustrator or other vector based document. I'm creating all these svg's, so allowing output to be read by an svg master manipulator seems smart.

Weekly update

2007-06-18T11:43:00.001-04:00

This past week I:

Met with David and got feedback on my design document.
Wrote a map preview app that uses javascript and generates a random pie on a google map that is draggable and zoomable.

Next week's goals:

Update design document; post it to the wiki.
Decide on how to pass information from page to page (through form variables, writing/reading a data file, a database server like MySQL).
Design a data structure to be used.
Write a simple input page that allows uploading of a data file.
Link input page to preview page (the pie viewer that was written last week).

getting the preview pane working

2007-06-18T10:46:00.000-04:00

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:

Draw a circle on a map.
Draw multiple circles on a map.
Make the circles draggable.
Draw a pie on a map.
Make the pie draggable.
Make the pie zoomable.
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.

Links to useful documentation for working with javascript and Google Maps

2007-06-18T10:25:00.000-04:00

Prototype is an excellent javascript library that basically implements all those functions that you wish came standard but didn't. Yay! Thanks to Cyrus and Jack who pointed this out to me. The documentation is pretty good too.

Javascript documentation. Fairly helpful, but not very complete. I ended up buying O'Reilly's javascript book this weekend to supplement this. The book's proven to be extremely helpful so far.

HTML DOM reference. Helpful, but doesn't have an 'DOM Element' section, which is annoying. The O'Reilly book does though, which once again is great.

HTML DOM Element reference. On Mozilla's development site. Has links to other references on javascript that might be worth checking out.

General HTML Tag reference.

Google Maps API reference. It has all the functions, but it's a bit difficult to parse. It can be difficult to find what a function belongs to -- the headings need to be set apart more. Also, some example syntax would be helpful. All in all, it's a necessary resource, but difficult to understand.

GPolygon class examples. On the Google Maps API forum. Many helpful links that showed how they implemented circles, making them draggable, resizable, etc. Very useful reference.

Firebug debugger. I've been using this debugger for inside website stuff. It's generally awesome. You can view the DOM hierarchy, set break points, and generally debug your code with it. Only complaints so far are that the debugging functionality appears to be a line off for some reason and sometimes the program fails to recognize the breakpoints you set (just blows right through them).

Meeting with David -- design doc changes

2007-06-18T10:08:00.000-04:00

Met with David this week to go over my design document. Generally the comments were good, and we mostly talked about adding some features and how to pass data from page to page. Here are some notes and thoughts from the meeting:

Features to add:

I should add a feature on the 'manage data' page to group haplotypes together.
On the preview page there should be an expand option to make the preview map pane larger.
Instead of having a special .pgv format for my application, can we fit everything within a .kml that our viewer can read as well?

Passing data:

The next big design decision is how to pass the data from page to page. We have several options:
All through form variables?
By using a database server?
By writing and accessing our own output files?
What kind of data structure should be used to hold the data?

We also talked about what languages to implement all this in. I had been planning on using php for all the server talking stuff and javascript for within the webpage stuff, but David made the point that using two languages is probably totally unnecessary, can javascript be enough? I think that sounds great to just learn one. The only problem I see is that it may be difficult (or impossible) to do server interactive stuff using javascript. I'll have to investigate this more.

From this meeting, it became clear what my next step should be: to build a skeleton application. The goals are to

be able to display pies on a map
to link (and be able to pass data) from the input page to the display page.

David also encouraged me to use the programming resources at NESCent (namely Xianhua), so maybe next week after I've gotten my feet wet with javascript, we can meet up with Xianhua and ask some more detailed implementation questions.

Apologies -- a little behind on blogging

2007-06-18T10:07:00.000-04:00

Sorry, got a bit behind on blogging. The next few posts concern my progress this past week.

Weekly update

2007-06-10T23:03:00.000-04:00

This past week I put together a draft of my design document. I tried to be as comprehensive as possible and made some mock ups for each page the user will encounter. Any comments on it are appreciated!

After doing all this design work I realize that I need to learn a lot more javascript than I had expected. While I'll still be exporting KML to Google Earth, I'll be previewing the visualizations a lot more in Google Maps which uses javascript. This puts me a little behind, because I'll have to get caught up on javascript this week too.

To do this week:

Meet with David and get feedback on design doc.
Make changes to design doc; post on wiki.
Familiarize self with javascript fundamentals
Implement the basic pie chart generation functionality. Functionality should include:

Draw a pie on a google map.
Plots multiple objects (working up to pie charts, but starting with placemarks) on a map.
Basic import of data.
Basic export to kml.

Detailed design document, draft 1

2007-06-10T20:29:00.000-04:00

If the user selects 'input manually',

The default numbers of haplotypes and populations are set to 10. Users can update these values to get the appropriate number of rows and columns in the data matrix. Unless the data matrix is small, the user will likely have to scroll within the table to input all the data. To facilitate this the population, lat, and long columns and the header row will be frozen. After the data is saved, the application checks the input. If the data is validated, we go to

We arrive at this page once the data have been validated (whether input by hand or uploaded). The purpose of this page is to allow the user to include/exclude populations and/or haplotypes. By default all populations and haplotypes are included. After any edits the user is taken to

This window previews and allows the user to edit the visualization. There are 3 possible visualizations: 1) Show just the sampling localities. On this option, the map options 'haplotype color', 'pie size (absolute)', and 'pie size (relative)' are grayed out. 2) Display with circles relative to the sample size for each locality. In this case, the map option 'marker appearance' is grayed out. 3) Display full haplotype information for each locality. In this case, the map option 'marker appearance' is grayed out.

When editing any of the map options a panel will pop out with options for that task. Map option definitions:

marker appearance: select what icons you want to identify each population
haplotype color: select colors for each haplotype
pie size (absolute): set the max diameter for each circle or pie
pie size (relative): choose if pies are all the same size or relative to the sample size; allows the user to set the bounds on the sample size bins

The map itself is fully functional. Users can zoom in, pan, and access satellite imagery as they can in other google maps applications. Furthermore, the users can click on drag any of the markers, circles, or pies to reposition them. This should be very useful especially for avoiding overlapping pies. If there's time, I'd like to add a button here for 'auto-fix overlapping pies', where the application detects collisions and repositions the pies for the user.

Below the preview screen is the legend. It shows the current color of each haplotype as well as the relative circle sizes and their corresponding sample sizes.

I know on the mock-up the preview screen is fairly small. However, the page will scale with the window, so it should be big enough for most folks. I will also consider moving the 'map options' below the map, so the map can be bigger. I was thinking, though, that the user might find it annoying to constantly scroll up and down to see the effects of the 'map options'.

Now to export the finalized map and legend.

From this page the user can export the visualization in four ways. It's important for the user to do the repositioning, coloring, and other editing work here before exporting to Google Earth. It's not possible to click and drag polygons in Google Earth as it is in Google Maps. If the user selects the .jpg option, they will be prompted to choose either saving the map and legend together or separately. The other formats handle the map and legend separately anyways.

Error handling: If the application has trouble reading the input file, then the validation will fail and generate this error page.

The user is then directed back to either uploading or manually inputting their data.

Overall flow chart for the application

2007-06-10T19:31:00.000-04:00

In words:
The user starts by inputting their data. There are three options for data input. After the data has been input, we validate that the data is appropriate and interpretable. If not, we send an error message to the user, and ask them to resubmit their data. If the data input is successful, we display the data back to the user and allow the user to include/exclude any populations and/or haplotypes. Following data management, the user is taken to the preview visualization page. Here a google map is displayed showing a visualization of the data. There are various map and view options here that update the page. The user can also return to the data management screen and edit previous choices. Finally, the visualization can be exported in four formats.

Weekly update

2007-06-03T21:51:00.000-04:00

This past week I...

Explored Google Earth and its APIs.
Figured out an algorithm for calculating vertices for drawing "circles" on a map.
Figured out how to write a pie chart in KML.
Explored Google Maps APIs.
Learned some javascript.
Learned how to embed Google Maps in a web page.
Have a better idea of what the overall design of the program will be like.

Next week the focus is on fleshing out the application's design. I will...

Produce a page by page description of what the user sees.
To do so I will consider:

How to input data. Are they going to upload files, input in a text box? What format?

How to export data. Format? Data persistence? Can users store data, results, maps, etc.?
What is the viewer? Google earth? Google maps?
How large are the pie charts going to be in comparison with the geography?
How do we deal with the problem of overlapping pie charts?
How are we going to color the pie charts? What if there are large numbers of haplotypes, how do we color them all distinctly and usefully?

The results of these decisions will be a comprehensive design document posted on the wiki.

Some notes on Javascript

2007-06-03T21:33:00.000-04:00

To use the Google Maps API's I'll need to know javascript. Here are some things I learned today:

Javascript has funny objects. Even functions are objects. And there's a lot inheritance going on.

For instance, if you want to create a new function that is a subtype of some class; you must implement all the appropriate "Abstract Methods" of that class.

Javascript ties everything to your html document through the DOM and DOM events. Examples of DOM elements are <div>, <body>, etc. DOM events are events that are generated by certain actions in the document like loading, clicking, moving, dragging, etc. Easiest way to think of GM is that each map instance is tied to a specific <div> or other element in your DOM. Event handlers are functions that get called when a certain event occurs and then does something.

Some useful websites:
Google Maps API
HTML tag list
Javascript DOM reference

Playing with Google Maps

2007-06-03T21:18:00.000-04:00

Yay! After playing around with Google Maps I feel fairly confident that we'll be able to at least preview the maps in GM and allow the user to manipulate the document in various ways.

For instance, I was able to create a rectangle overlay that was then draggable. You can imagine users dragging the pie charts around to avoid collisions and so forth. Pretty neat functionality!

image overlays vs. polygons idea revisited

2007-06-03T18:33:00.000-04:00

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!

2007-06-03T18:16:00.000-04:00

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.

Lat and Long in KML

2007-06-03T17:51:00.001-04:00

While you can enter coordinates in "lat, long" pairs in the finder, in KML, within the tag, the order is "longitude, latitude, altitude".

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

2007-06-01T17:04:00.000-04:00

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?

2007-06-01T14:13:00.000-04:00

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

oblong circles

2007-06-01T14:05:00.001-04:00

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.

Algorithm for drawing a circle

2007-05-29T15:54:00.001-04:00

Given:
A starting location with longitude, clong, and latitude, clat all in decimal degrees.
The radius, r, in km of the final circle.
Points that define the circle are 0, pi/10, 2pi/10, 3pi/10, 4pi/10, 5pi/10, 6pi/10, 7pi/10, 8pi/10, 9pi/10, pi, 11pi/10, 12pi/10, 13pi/10, 14pi/10, 15pi/10, 16pi/10, 17pi/10, 18pi/10, 19pi/10, angles from the central point with radius, r.

For each of 20 points that define the circle:
theta, the angle in radians, that changes from the horizontal for each point.

1. Calculate (x, y), the cartesian point that is x km east, y km north relative to the central point.
*a. x = r*cos(theta)
*b. y = r*sin(theta)

2. Calculate y'', the latitude of the point in decimal degrees.
*a. y' = y/111.12km/degree
*b. y'' = clat + y'

3. Calculate x'', the longitude of the point in decimal degrees.
*a. x' = x/[(111.320 + .373*sin(y''))*cos(y'')]/degree
*b. x'' = clong + x'

--tested this --
This doesn't quite work. The 'circle' isn't so much a circle but a flat heart shaped thing. If I use clat instead of y'' in the calculation of x', it looks more symmetrical, but it is still a bit stretched in the vertical direction. Here's the KML. Hmmm...

latitude longitude facts

2007-05-29T15:16:00.000-04:00

1 minute of latitude = 1852 meters (very close approximation)
1 degree of latitude = 111.12 km
1 degree of longitude = (111.320 + 0.373sin²φ)cosφ km, where φ is latitude
(information from wikipedia)
For 21 points (last points overlap), each point is 18 degrees away from one another.

note to self: escape characters in html

2007-05-29T15:13:00.001-04:00

Remember:

< = <
> = >

Playing around with Google Earth

2007-05-29T13:22:00.001-04:00

Notes:

You can easily move placemarks by accessing their 'properties' then clicking and dragging. You can NOT easily move polygons in the same manner. Maybe that should be a design consideration.

Found a great application that makes all sorts of graphs in GE, called GE-Graph.
He (?) makes the circles as groups of 21 points (first and last the same), so not a true circle.

If you want multiple placemarks within the same file, they must be enclosed by a <Document></Document> tag. Otherwise, GE complains about having too many 'roots'.

Within the <Document> tag you can define a lot of styles using <style id="foo"></style> then reference those styles in the document using <styleUrl>#foo</styleUrl>.

Within a <Placemark> you can only have one point, polygon, etc. Otherwise, it only shows the last one. Unfortunately you can't click on polygon's to view their properties or description. It seems like the easiest way is to create two placemarks for each location. One that is a point, that the user can click on easily, the other the pie chart. Put these data in different folders (<Folder></Folder>) so you can easily turn off the labels.

Learning to use Subversion

2007-05-25T15:44:00.000-04:00

Here are some pages I found useful in getting TortoiseSVN set up on my machine and talking to my source code repository hosted by google.

Explicit, simple instructions with screen shots.
Somewhat more complicated instructions, but more detailed
Google's hosting page walkthrough.
Manual for TortoiseSVN.

Set up code repository with google

2007-05-25T10:49:00.000-04:00

Set up code repository with google. It was pretty easy to set up, but of course has no content yet. I'm not totally sure how to get set up using subversion yet.

Exploring PHP

2007-05-18T17:26:00.001-04:00

I finished working through the simple PHP tutorial today. It was pretty helpful. Here are my notes:

Hint: "It's not working!?! Why?!?"

Check: Is Apache turned on? duh...

php tag:

<?php to start a php tag
?> to end the tag
Use the tag within an html file to jump in and out of php.
Can jump in and out of php/html within a php block even.

Variable info:

Variables always start with a '$'.
Can see all reserved variables through phpinfo().
Variables can be pretty much the same types (bool, int, string, etc.) that they could be in C++, but you don't need to declare them that way. Also some mixed types and type casting is allowed.

Helpful functions:

strpos($haystack, 'needle'); //finds the string needle within the variable haystack. Returns the position, or FALSE.
int count (mixed $var [, int $mode] ); //Returns the number of elements in var, which is typically an array, since anything else will have one element.
PHP can access html form info easily. See tutorial for help.

Things to explore:

It seems like you can use php alone as well, without html surrounding it. Is that true?
- For instance, <?php phpinfo(); ?> works fine in its own file.
What is "Model View Controller"? It sounds like a way of organizing your code to make it more readable and understandable.
The PHP manual is pretty helpful and has a lot of examples and documentation for functions, global variables, etc. I'm impressed with how easy it is to understand.

Wiki updates

2007-05-16T15:17:00.000-04:00

I edited the EvoViz site and added PhylogeoViz to the list of programs. I've got to come up with a better name. Phylogeoviz is pretty boring. Ah well, that can come later on in development. I also added the detailed project plan to the wiki.

Detailed project plan

2007-05-15T21:26:00.000-04:00

Here's my preliminary weekly project plan. Dates refer to the beginning of that work week. Any comments are appreciated!

Now til Start:

Phase 0: Getting development environment set up
- Set up homepage, wiki, repositories, etc.

May 28

Phase 1: Exploratory phase
- Learn how to embed maps on a webpage.
- Learn the relationship between Google Earth and Google Maps.
- How are they the same, how are they different? What can you do with one that you can't do with the other?
- Explore KML and general XML.
- Explore Google Earth and Google Maps APIs.
- Create a pie chart using KML.

June 4

Finish exploratory work if neccessary.
Phase 2: Finalize design
- Page by page description of what the user sees.
- How to input data. Are they going to upload files, input in a text box? What format?
- How to export data. Format? Data persistence? Can users store data, results, maps, etc.?
- What is the viewer? Google earth? Google maps?
- How large are the pie charts going to be in comparison with the geography? How do we deal with the problem of overlapping pie charts?
- How are we going to color the pie charts? What if there are large numbers of haplotypes, how do we color them all distinctly and usefully?
- The results of these decisions will be a comprehensive design document posted on the wiki.

June 11

Implement the basic pie chart generation functionality. Functionality should include:
- Basic import of data.
- Basic KML output writer.
- Function that draws a pie chart.
- Function that plots objects (working up to pie charts, but starting with placemarks) on a map.
Write corresponding documentation.

June 18

Combine pie chart generation and chart plotting functionality.
Write the functions that allow adjustments to the output (e.g. changing pie sizes, allowing the user to change haplotype colors, etc).
Write corresponding documentation.

June 18

Work on a function that allows the user to move pie charts around spatially (and to save those movements).
Write corresponding documentation.

June 25

Write the functions that display the KML back to the browser.
Write corresponding documentation.

July 2

Prepare for Botany conference.
Get code submitted to Google for midterm code check in.
Get a prototype of the viewer available for download.
Make sure I'm meeting the midterm evaluation criteria

July 9

Work on bugs that arose from earlier code.
Revisit full data manager design. Finalize UI design.

July 16

Implement UI for the data import functionality.
Expand (?) data files that are acceptable (haplotype, genotype, etc.)
Write the corresponding documentation.

July 23

Implement UI for customizing data analysis.
- Example: the user should be able to select what loci/alleles/populations to include/exclude in the analyses.

July 30

Implement UI for output data manipulation.
- Example: the user should be able to change the relative pie sizes, move pies around, change haplotype colors, etc.

August 6

Implement functions that allow the user to save the map visualization (e.g. jpg) or to save the KML file.

August 13

Perform user tests.
Ensure that the viewer and the data manager are well integrated.
Deposit code with Google.
Update website with new product, and all documentation.

August 20

Done coding. Final evaluations.

Installing PHP

2007-05-15T16:08:00.000-04:00

I downloaded and installed PHP 5.2.2. Unfortunately, nothing happened. Somehow, the installer hadn't updated Apache's httpd conf file (which is inside the conf directory) to load php correctly. I think for most people the installer sets this file up for you automatically. Anyways, the useful directions I followed are here, where basically you insert 3 lines into the httpd file. Now I have "hello world" going on! Yay!

Installing Apache

2007-05-15T16:03:00.000-04:00

Well, that's harder than it looks. I downloaded Apache for me to practice with a web server. For some reason it installed but was unable to start. Turns out that the port it wanted to use (port 80) was already in use by another program (turn out that Skype was the culprit!). I turned off Skype's ability to use that port, and voila! I now am hosting a page that says, "It works!". Great!

Goals for this week

2007-05-13T22:46:00.000-04:00

~~Complete detailed project plan, submit it to David, post on wiki.~~
~~Focus on how to generate these KML files:~~
~~Install Apache and PHP on laptop.~~
~~Investigate PHP.~~
Investigate java as an alternative.
~~Set up code repository on google.~~

Wiki updates

2007-05-13T22:31:00.000-04:00

I worked on adding the project to the Phylo SoC wiki, and creating the wiki home for the project. Was a bit more time intensive than I had expected. I put the overall project plan up, but haven't added the detailed timeline yet. I'll need to do that this week.

I also made this blog public.

Researching KML

2007-05-13T19:52:00.000-04:00

So I'm on google earth's KML tutorial page. Some highlights and considerations:

Google Earth (GE) can draw some pretty cool polygons and such. However, the edges of these polygons are defined directly by lat/longs. I'm not sure how this will play into generating these coordinates per population as appropriate to the data. The pies would be defined by multiple points, not points all connected to some central point, so centering, etc may be tricky.

GE's KML seems pretty similar to html markup styles. I don't think it'll be too hard to learn. It looks like you can define global styles (<style id="">) that you then can call appropriately.

You can link to stuff on the network as well. Check out "Network Links" in the future. You can link to static stuff (images, another kml file, etc.), but you can link to dynamically generated stuff too. For instance, you can connect to a cgi script. Also, you can send info about the current use (page view, what's highlighted, etc.), then use that info to generate some new kml, then feed that back to the user's GE. This could be a way to incorporate user feedback into the system. But it sounds like it could be tricky.

Another trick: to add html markups, use the CDATA element. Example, add:
...all usual html coded stuff here...
]]>
Otherwise, you'll have to escape all the < and >.

Knowles recent paper

2007-05-13T19:51:00.000-04:00

David sent me this recent paper from the Knowles camp that has some nice graphics associated with it. Judging from the pie chart designs, it looks like the graphics were created in Illustrator.

Google Earth Workshop - from CIT

2007-05-07T14:13:00.000-04:00

Run by Andrea Novicki through the Center for Instructional Technology.

Interesting, inspiring workshop. Went over how to create placemarks, what polygon, paths, overlays are. Basically did a tour of the general functionality of Google Earth. Interesting features I didn't know about:
can do 3D polygons
can have timelines, show changes over time
can implement tours
has a "ruler" to measure distances along paths, etc

Most important new thing: can share maps through the google earth community. Lots of neat maps already available, you can share your work easily.

Minutes from meeting 1 with David, Hilmar, and Xianhua

2007-04-27T17:04:00.000-04:00

Yesterday I had my first meeting with my mentor, David, and others from NESCent (Hilmar and Xianhua). See the "meeting1 agenda.txt" for agenda items.

We answered most of the (I) general IT support questions.

We'll be using some corner of EvoViz for documentation, ideas, pages, project plan, etc. David reassured me that he doesn't have ny particular format or structure in mind for the page.
I should set up the code repository through google.
The development/testing server will be hosted by NESCent
For now the project homepage can be the wiki. We can reevaluate later if there needs to be an 'official' page somewhere.
For mailing list help, wg-phyloinformatics sounds right.

A lot of the meeting centered on what language should I learn and be used for the application. Hilmar said, why not C++!?! David is partial to java because he wants to learn it. There was a lot of confusion about java and javascript on my part(which later Jack cleared up). Hilmar mentioned that javascript is difficult because there is no debugger. Xianhua mentioned that PHP is not object-oriented like C++. Their suggestions were for me to consider the following in my decision: what do I want to get out of this summer? better understanding of java? php? let that guide my decision. What libraries are available in each language that would be useful? I think Xianhua mentioned grass funtions or open source GIS functions in C, hmmm... Hilmar made it sound like they could make any of these languages work server side at NESCent.

We didn't discuss the project plan or overall timeline, or expectations too much. I told David multiple times that I am unable to devote full time to this project. I did mention keeping the project to something within 10-15hrs/week. He seemed ok with this. Hilmar said that we are evaluated based on our completion of milestones based on our project plan. I think that just means I need to make a realistic plan with the scope of 120-150 hours total for the project.

Things to do in the next two weeks:
Research languages.
Decide on a language.
Do phase 0.
Write up detailed (weekly) project plan.
Post things to the wiki.
Post things to NESCent's SoC wiki.