Azavea Labs » sourcemap

Ignite: Spatial, Boston

David Zwarg — Tue, 15 Dec 2009 16:51:08 +0000

I got the opportunity to present at Ignite: Spatial, Boston a couple weeks ago. I was fortunate to present Sourcemap.org in the company of other Boston area techies doing some cool work in laser scanning, CityML, social media and more.

All the videos are on YouTube. The presentation summaries are also online in this Google Doc.

Enjoy your spatial ignition this morning.

Of Splashes and MoOMs

David Zwarg — Mon, 27 Jul 2009 16:18:06 +0000

Sourcemap made #10 in Mashable.com‘s list of how to use the web for socially responsible shopping, and has been picked up by a few other blogs. One that caught my attention: MoMB, the Museum of Modern Betas.

I had to check the MoOM, to see if it was a part of their collection. No? Not even in the Annex? Oh, well. Maybe they don’ t do beta.

Azavea R&D: sourcemap.org (pt. 2)

David Zwarg — Wed, 03 Jun 2009 15:13:58 +0000

So why does the International Date Line (IDL) cause so many headaches? It seems like a really simple problem, but it ends up touching a bunch of mapping concepts, none of which are easily dealt with. I ran across this when working on the Sourcemap project, when we wanted to relatively realistic travel paths. When I say “relatively”, I mean, don’t travel from Japan to California via France (and not via Kayak, either).

For Sourcemap, we started visualizing larger and larger networks, and began noticing that nothing from China was ever connected to anything in North America vai the Pacific Ocean. When you want to visualize a globally connected network, it helps if the network knows that the map is a globe, and creates connections in the direction that minimizes the distance between points. Using the built in cartography of OpenLayers, we get the following map:

Where the network is always constrained within the rectangle of -180, -90, 180, 90 (x_min, y_min, x_max, y_max). I approached this a couple of ways, and the one that turned out to be the easiest exploits a lesser-known ‘feature’ of OpenLayers, whereby a Longitude that exceeds the coordinate system (e.g. -200) is indeed rendered on the opposite side of the IDL (e.g. +160).

This is excellent! Now I know that OpenLayers can render multiple instances of a feature in a single map. Instead of adding single vector features, I added multipart features{multipoint and multiline), with each individual feature in that multipart offset by 360 degrees from the next.

Interestingly enough, OpenLayers also does some flipping of your features when you cross the IDL. When you grab the map and pan across the IDL, your features will flip into the coordinate system that contains the center point of the map. For this reason, I created 3 versions of everything, and placed them at (x – 360), (x), and (x + 360). This allows for continuous coverage on the map, even when the features are flipped over the IDL.

The result:

Now the maps reflect more accurately the trip of objects around the world! Each line is the shortest path between points, and are allowed to cross the IDL if necessary. For the purposes of Sourcemap, it was important to be able to show these trips, since we are discussing ways of modeling the transportation networks of goods around the world.

Azavea R&D: sourcemap.org

David Zwarg — Thu, 14 May 2009 14:32:40 +0000

Azavea is a rare company. One of the benefits that we (full-time employees) earn is the ability to define our own research project after 6 months. There is a list of active research projects here. My personal interests took me to working with C. Dana Tomlin, and implementing a radial propagation tool for ArcToolbox, as well as collaborating with the MIT Media Lab‘s Tangible Media Group on the project http://www.sourcemap.org/.

I won’t get into what sourcemap is (that’s already been done), but I thought it would be cool to mention some of the technical challenges that the project was/is facing, and what we’re doing about it.

First, the project started out with maps from a free, proprietary mapping API. This was a great stepping off point, but as the maps and networks became more complex, that API started to break. I advocated that the project migrate to an Open Source JavaScript mapping library, by the name of OpenLayers. This helped us overcome that barrier to complex maps.

Next, we wanted to change the cartography from simple lines between points to something more ‘stylish’. The problem that we experienced was that it was difficult to discriminate the paths of colinear parts of an object. To solve this, we added a slight arc to the lines. This technique makes it easier to discriminate the connections between colinear parts and an object.

Time to bust out the trigonometry again! I doodled the following sketches on a mousepad weekly planner. I wanted an offset of the line in the vertical direction for most horizontal lines. This calculation got me started, but then I realized that it would be weird if the arcs suddenly swapped sides if you passed the Y axis (e.g. from 359 degrees to 1 degree).

So I added another step, which attenuated the arcing, starting at 45 degrees from either side of the Y axis, and gradually decreasing to no deflection in the Y direction.

The result? A cool looking network of lines that are clearly distinguishable! You can see it in action here.

We’ve got even more improvements on the way for the map, and I think it will make it a really compelling, and intuitive visualization of global supply chains. Watch this space for the next installment.