A number of months back, I first encountered the Simile Timeline widget. It was exactly the sort of tool that I'd been dreaming of for quite some time, as a means of navigating through time-based information. I'd seen a number of timeline implementations in the past. Many of which appealed to me. However, the apparent ease with which the Simile Timeline widget could be integrated into an existing web application was the real kicker.

Since much of what I do in the web-based world involves using ZOPE and Plone, my focus turned to integrating Simile with an existing Plone site. The initial work kept it fairly simple. And what I'd learned then, I've documented in the how-to document titled Add a Timeline. Since then, I've incorporated the widget into couple of client projects, including one where a timeline view (implemented as a Zope 3 browser view class) was used in a custom Archetypes-based product for Plone.

The other thing that I'm very keen on is the use of maps, for visualizing place-based information. And for this, I'm in love with tools like Google Maps and Yahoo Maps.

A few years back, I became very interested in the idea of storing information within my digital photos about where they were taken. A process, I soon learned, which is called geocoding, or geotagging. This is when I became aware of a project called the World-Wide Media eXchange. The site - which formerly resided at wwmx.org - had a couple of very interesting ways of visualizing the geotagged photos stored within. The primary visualization involved the use of a map (the same technique now used by the Flickr map view) to plot where each photo was taken, however what was equally intriguing was a slider control which allowed one to view photos taken within a certain time-span. This added a very interesting extra dimension to the navigation, creating a unique geo-temporal navigation system for viewing photographs.

This idea planted itself firmly into my memory.

Last week, the idea began to wiggle around in my brain. And I wrote a note to myself to think more about two things in particular:

• events which have a single location (point)
• events which have multiple locations (path, track, trajectory)

To use the WWMX or Flickr map idea, the first item would appear as a point on the map. The second item, however could be much more interesting. And perhaps an effective way to imagine how this might be applied, is to use a a video rather than a photograph as the item to be displayed on the map. In this case, if each frame of video was geocoded, then a path on the map could be used to represent the location of the camera at any given time throughout the length of the video.

This brings me to what I ended up finding this evening, and the topic of this particular post; which is Timemap.js.

Timemap.js is a Javascript library to facilitate using Google Maps with a SIMILE timeline. The library allows you to load one or more datasets in JSON or KML onto both a map and a timeline simultaneously. By default, only items in the visible range of the timeline are displayed on the map. (excerpt from: http://code.google.com/p/timemap/)

I just love it when there's something which I'd like to be able to do, and some bright soul has already created a working solution. The knowledge of which is a mere Google search away. (Incidentally, it was this blog post which pointed me in the right direction.)

The examples that are provided on the timemap site are interesting too:

• Simple Three-Item Dataset (using inline JSON data)
• Post-Election Violence in Kenya (using KML data)
• Artists & Authors of the Renaissance (using JSON data from a freebase.com query)

Now that I'm aware of the existence of Timemap.js, it's time to come up with a practical application of it which would be useful to me. That shouldn't be too hard.

Situation:

I have an export of the portal object (not the entire ZODB) for a Plone site which was residing in an old Plone 2.0.5 based instance. It needed to be moved onto a newer server which has Plone 3.1.5.1 running on it. As it turns out, the migration path isn't quite so simple.

Action:

Initially, I had exported the portal object and attempted to import it directly into the ZOPE instance on the new server. This, unfortunately didn't work at all. In fact, the portal_migration tool in Plone 3.1.5.1 doesn't even allow a portal from pre-Plone 2.1 to be migrated. So, this meant that the migration likely had to be performed in lock-step fashion, using increasingly newer versions of Plone.

The first step was to find a version of Plone (later than Plone 2.1) that was sufficiently old such that the portal_migration tool would allow a Plone 2.0.5 site to be migrated. With this migration performed, it should then (theoretically) be possible to export the portal object, then import it into a Plone 3.1.2 instance (3.1.2 just happens to be what's handy on one of my development boxes).

My first attempt involved installing Plone 2.5.5, as it's the final release in the Plone 2 series. The migration using it was unsuccessful, however, as it failed somewhere around the stage where it was migrating the site from version 2.1.4 to 2.5. So the next (and successful) attempt involved installing Plone 2.1.3.

With this in place, it was then possible to successfully migrate the site to Plone 2.1.3. And this was also good, as it's also above the minimum requirement of Plone 2.1. After going through the newly migrated site, it was also necessary to perform a few checks to make sure that the site was still functional. It was.

Next, I exported the portal object and attempted to import it directly into the ZOPE instance with Plone 3.1.2 installed. In the spirit of the previous luck, this also failed. However, it wasn't a failure which would require migration using another intermediate Plone version. The failure was simply due to the fact that there were a couple of MIME types which were missing from the mimetypes_registry. So, in the Plone 2.1.3 site, I added the following MIME types to the mimetypes_registry:

• Name, Mime-types, Extensions, Globs, Binary?
  
• Web Intelligent Plain Text, text/x-web-intelligent, {blank}, {blank}, no
  
• Markdown, text/x-web-markdown, markdown, {blank}, no
• Textile, text/x-web-textile, textile, {blank}, no

With these added, the portal object was exported once again, then re-imported into the Plone 3.1.2 instance. This time, the import was successful. Next step: attempt to use the portal_migration tool on it. And of course, this again failed.

This time the error was as follows:

• Attempting to upgrade from: 2.1.4
• Upgrade aborted
• Error type: exceptions.NameError
• Error value: global name 'chain' is not defined

OK, so I was likely trying to take too large a step again. Hence, the next step was to setup a Plone 2.5 instance and import the portal into it, then perform the portal_migration dance.

A Plone 2.5.5 instance was created and the portal imported successfully. Upon using the portal_migration tool, there was a minor problem but it was due to a group in the acl_users folder which needed to be fixed. Once this was corrected, the portal_migration tool happily went about its business and updated the site from 2.1.3 to 2.5.5. The portal_atct tool also wanted some attention, as next to its icon was a red exclamation point. Upon inspection, the tool notified me that the version of ATContentTypes on the filesystem was newer than what was in the portal. This too was quick to update.

At this point, I had a portal which had been successfully updated from Plone 2.1.3 to Plone 2.5.5 which was finally exported.

The exported portal was copied back over to the import folder on the server with the Plone 3.1.2 instance and re-imported. As before, the import was successful. However, unlike with the previous attempt, the portal_migration step was also successful this time. Finally: a working Plone 3 version of the portal. The last step was to verify that everything in the site was still functional after the upgrades. From this point, the final migration from Plone 3.1.2 to 3.1.5.1 would be a non-event.

Result: