Sunday, June 15, 2014

Mapping Historical Events in Chronological Order: geochrono

In my history of physics research, I've come up with a data visualization application I need that I can't find.  It would be nice to be able to author a list of events and people tied to places and dates and then display them on a map in chronological order.  Using this visualization of information, I'm hoping to find individuals in my research who may have known or worked with each other, or who might have been instrumental in, or related to events in the history of physics.  I did my due diligence and tried to find a free application that already existed, but was unsuccessful.  Here's the open source GitHub for the new application https://github.com/hcarter333/geochrono .  The details follow.

Failing that, I wrote down a very brief description of what I'd like the app to do:

I'm trying to find relationships between individuals that may not be obvious based on their chronological locations. I find myself in need of a tool that will let me map the locations of events and people chronologically, in a KML for example.

and I jotted down a few short requirements


  • Load kml of events and display in table forma
  • Allow entry of data and metadata, (pictures etc…), into table for generation of kml and chronology tour
  • display kml as tour on .js embedded Google Earth map
  • allow user to specify range of tour, which markers to include or exclude, and view screens of the world to watch. Do the last by turning off panning

A few years back, +Shankar Hemmady and I wrote a book, Metric Driven Design Verification about a methodology and processes for bringing a chip design project to fruition successfully.



I've just been out to the DAC conference where this metric driven methodology is being adopted wholesale.  I want to see if I can practice what I preach, so I'm going to try to follow the methodology laid out in the book.  Towards this end, I've setup and open-source project at GitHub, (note:  never open source your chip project, your boss will have a conniption), so others can join in and also so that I can make use of the built-in code revision control system and issue tracking system.  Fun fact:  issue tracking systems used to be called bug tackign systems.  I attended several meetings where it came out that the creative types are generally hurt when their code is called buggy, but don't mind the word 'issue' quite so much, hence, issue tracking systems.  Parts of the methodology, which isn't so different than the extreme programming/refactoring method for software, which I'll be following will be:

Documentation of feature intent along with a testcase that will check that each atomic aspect of the intent has been verified.

Definitions of the roles on the project
I'm hoping to eventually enlist the aid of others on this project, because as much fun as I'm having, man, do I not have the time!  Towards that end, I'm hoping the project will have the following roles/stakeholders who won't all be me.

Coders:  See the above

Web designers:  Because it would be nice if the site were pretty.  This would hopefully encourage more interested folks to use it to two ends.  First, more use means finding issues sooner and fixing them more quickly.  Second, as with all my sites, we'll put some ads up to generate revenue to pay for things like Google server space and coffee.  I think I've also finally figured out a good working model for open source sites that include ads.  If you serve it, then you fork off the module that displays the ads and change the account ID.  To the person paying the server fee go the (very minimal) spoils!  Also, the best served/prettiest version hopefully winds up being the survivor and the rest of us just get to use the tool we wanted in the first place without having to fuss with it!

History Researchers:  Because the quickest way to find out you've implemented the wrong thing is to put the tool in front of someone that needs it.  I of course think I know what I want, but the more perspectives on what would be useful the better.  Also, the sooner they get in the better.


Tracking Metrics
I'll be tracking metrics on everything I can think of for the project.  At first blush, this will be the issue database, the number of testcases passed and failed, and my task list.  The task list will keep me honest.  I only have about a half hour a day to spend on this.  Logging what I do and how long it takes will hopefully keep me in check.

Reusing/Refactoring Code
The code will reuse the guts of three other applications mapmyfriends and findsat and aprsdotfly.  All of these applications were written in kind of the worst style possible.  They're just straight-line scripted with a handfull of functions.  What they do include, however, is code that initiates Google Earth properly,code that sorts through lists of objects to be mapped, and code that plays kml objects as movies on Google Earth.

mapmyfriends

 findsat

aprsdotfly


References:
1.  Verification book
 http://books.google.com/books?id=HgZWmY9TTVsC&lpg=PR1&dq=hamilton%20carter%20metric%20driven%20verification&pg=PR1#v=onepage&q=hamilton%20carter%20metric%20driven%20verification&f=false

2.  findsat
http://copaseticflows.appspot.com/findsat

3.  aprsdotfly
http://copaseticflows.appspot.com/aprsdotfly?tour=ahRzfmNvcGFzZXRpY2Zsb3dzLWhyZHISCxIJQVBSU1RyYWNrGIv0xBUM

4.  geochrono code repository
https://github.com/hcarter333/geochrono






No comments: