This is a mostly working hack that uses XSLT to transform the [[Plazes]] “traces” XML file into a format suitable for feeding to Google Maps. I used a variety of Google Maps hacking sites to help me put this together. Because Google hasn’t published an API for this feature, it all exists in a shadowing alley world; enjoy at your own risk.

The result, which you can see live here, looks like this:

That’s a map, centred on Charlottetown, showing all of the Plazes that I’ve visited in the last 60 days. If you zoom way, way out, you’ll see additional Plazes in Montreal and Copenhagen too. Here are the building blocks:

• XML locations file (from Plazes)
• XSLT file (transforms the XML file)
• XML file for Google Maps (result of the transformation)

I used TextXSLT on my Mac to transform the Plazes XML file using the XSLT file; there are a variety of other tools available for this, including the handy web-based W3C XSLT Service.

If you look at the source of the demo HTML file (substantially taken from Unofficial Google Maps Embedding How To), you’ll see it refers to “demo.xml,” which is where I saved the XML file that resulted from the transformation.

Notes on the result:

• The XSLT file is somewhat more complicated by the fact that Google Maps needs latitude and longitudes expressed as positive (N and W) and negative (S and E) numbers while Plazes’ traces file uses positive numbers with N, S, E and W appended as appropriate.
• The Plazes on the map are “clickable,” but the name and address of the Plazes don’t show up in Safari (they do show up in Firefox). Not sure why.
• Some of the Plazes are showing up in the wrong location. This isn’t a problem introduced by the demo, or the fault of Google Maps: it appears to be a problem with Plazes’ geocoding system (wherein an address is translated into lat/lon coordinates). The Harborside near Delta Hotel Plaze shows up in the wrong place, for example, as does MarinaGrill.
• The map is the barest possible example of a standalone Google Map: obviously there is much sophistication that could be added.

I can also imagine many ways in which this demo could be enhanced:

• Different colors for “occupied” Plazes (would require a call to the Plazes server, somehow)
• Pop-up could link to Plazes page, could show icons of Plazes users currently at that location, etc.
• Could uses Google’s driving directions layer to show the “trace” — movement from Plaze to Plaze.

I welcome comments and suggestions for improvements and encourage others to build on this.

On Monday, Wednesday, and Friday I pick up [[Oliver]] from pre-school at Holland College. I usually walk from the office up Fitzroy Street to Weymouth, then down Weymouth to Kent, and in the back door of the Holland College Charlottetown Center. At the back door I have the choice of stairs or this ramp:

I always take the ramp. Indeed I look forward to talking the ramp. It’s made out of metal grating, and is just bouncy enough so that walking up it provides a very pleasant “floating on air” sensation. The ramp traversal is one of the highlights of my day. At least on Monday, Wednesday, and Friday.

I did some experimenting this afternoon with taking my Plazes XML Traces file and using XSLT to transform it into RSS. I didn’t end up with a complete solution, but I came close:

• XML file (from Plazes)
• XSL file (that I created)
• RSS file (result of the transformation)

The problem I ran into is that in the Traces file dates are represented like this:

<location arrival=”2005-06-10”>

Whereas for the RSS file I need something that looks like this:

<pubDate>Sat, 25 Jun 2005 17:36:08 +0100</pubDate>

I need a way of converting dates from one form to another in pure XSLT. I found references here and here that suggested ways around XSLT’s poor date support, but I haven’t implemented them here. As a result, the resulting RSS file is missing a <pubDate>.

I welcome suggestions on how to improve this.

Update: You can use the W3C web-based XSLT processor to do the transformation: the result is RSS that can be fed to an aggregator or newsreader. The pre-packaged URL is here. To reduce load on their XSLT processor, however, please don’t subscribe to this URL.

A new [[Plazes]] feature, “Traces,” lets you publish an XML file of all of the Plazes you’ve popped up at. Here’s 60 days of me, for example. Next step: use XSLT to convert this into an RSS feed.

In social network analysis we talk of nodes and edges. If we were to diagram the social network of a recent lunch at the [[Formosa Tea House]], for example, it might look like this:

In this case the nodes are Peter, Steven and Dan and the edges are the “glue” that connect us.

It seems to me that we often tend to treat nodes as more important than edges when we’re building technology tools: we’re more interested in the nouns than the verbs.

I think this is especially true when it comes to web-based photo gallery systems: these are traditionally designed to be “photo-centric.” Which, on first blush, makes perfect sense; they are photo galleries after all.

Look at this photo of Dan or this photo of me.

The gallery systems these photos find themselves in (the silverorange Photo Gallery System and the open source Gallery system, respectively) treat the photo as the most important aspect of their operation. While both systems have a basic taxonomy or hierarchy into which the photos can be categorized, this is a secondary aspect of their operation. And in neither case does browsing the gallery by following the taxonomy offer much additional insight or depth to the experience.

These gallery systems, in other words, emphasize the node over the edge, and in doing so they assume that what we want to do when we use a web-based gallery is to look at photos, in much the same way we would using a physical photo album.

Over the past few weeks I’ve started to use Flickr as a gallery system, and I’m struck by the degree to which in that system edges are equal to or more important than nodes.

Yes Flickr is still a photo gallery, but with tags and groups and contacts and all of the other edge-centric functionality built into the application, in Flickr its the relationships between photos (and, to a lesser extent, the relationships between photographers) as much as the photos themselves that are important.

Part of my resistance to using Flickr to this point was that I was uncomfortable with the notion of “my stuff on somebody else’s servers.” After chatting about Flickr with [[Jacob Friis Larsen]] at [[reboot]], though, I realized this stubbornness was getting in the way letting my photo-flow become part of a community photo-flow and, with that, a system where it’s not so much the photos that are interesting, but everything that surrounds them.

So this morning I took this photo of a crane. It’s a crappy photo. I took it with the crappy camera on my [[T610]]. But that doesn’t matter.

When the photo rides into the flow on the backs of my blog post and this Flickr tag and this Technorati tag it’s not really the photo that’s important. It’s the moment in time. It’s the what of the photo not the how. It’s the digital idea forest that builds up around the photo. The photo becomes part of the web, part of the tagged miscellany.

It used to be just a photo. A simple isolated node. Now it’s got edges. And that seems much, much more interesting.

I came into the office this morning and found, to my surprise, that in the night a crane had arisen over the city. Charlottetown doesn’t get many Big Construction Projects, so this is a big event.

Susan Ormiston hosted The National tonight: what a breath of fresh air.

Suggested yesterday and codified today. Cool.

I get a lot of ideas. Most of them get lost to time, confusion or distraction. I’ve decided that I should try documenting my ideas, or at least those that pass a threshold of 8 or 10 hours of musing, in the Rukapedia.

So here’s the first one: [[Call Anywhere]].

Local afternoon show host Matt Rainnie is hosting a national radio show this summer called Lost & Found. Airs Saturdays at 1:00 p.m.