Let’s face it. Relational databases, such as MySQL, SQLite and PostgreSQL, are pretty cool – but nobody actually uses them. At least not in the day-to-day work with small to medium scale datasets. But why is that? Why do we see an awful lot of data stored in static files in CSV or JSON format, even though

• they are hard to query (you need to write a custom script every time)
• they are messy, as they cannot store meta data such as data types
• it is a pain to update them incrementally, say if some record has changed

Programmers are lazy people

The answer is that programmers are lazy, and thus they tend to prefer the easiest solution they find. And in most programming languages, a database isn’t the simplest solution for storing a bunch of structured data.

At least in Python, things really shouldn’t be this way.

So, say hello to dataset, a new Python library to simplify your every-days work with databases. In a nutshell, dataset makes managing databases as simple as reading and writing plain JSON files.

Here’s a brief list of the key features:

• Automatic schema: You never need to worry about the database schema again. If a table or column is written that does not exist in the database, it will be created automatically.
• Upserts: Very handy when running a scraper the second time: Records are either created or updated, depending on whether an existing version can be found.
• There are some nice query helpers for simple queries such as all rows in a table or all distinct values across a set of columns.
• Compatibility: Being built on top of SQLAlchemy, dataset seamlessly works with all major databases, such as SQLite, PostgreSQL and MySQL.
• Scripted exports: Data can be exported based on a scripted configuration, making the process easy and replicable.

Hope this comes handy to some of you, since I cannot live without the library anymore. If you want to read more, check out the full documentation at dataset.readthedocs.org?

Happy databasing!

You can do this using the colorRampPalette() function that comes with the grDevices package. Calling this function will return another function that you can call to generate the color palette.

> library(grDevices)
> palette = colorRampPalette(c("red", "yellow"))
> palette(5)
[1] "#FF0000" "#FF3F00" "#FF7F00" "#FFBF00" "#FFFF00"

By default, R uses the RGB color space to interpolate between colors. As I mentioned in earlier posts, this is not as ideal choice for data visualization. Fortunately, R allows you to interpolate in CIE Lab color space. Let’s write a quick function plotColors() to plot the colors. The function takes two arguments: palette is the palette function returned by colorRampPalette and n defines the number of color steps we want to display. Internally the function simply draws a bar chart without axes and with no spacing between the bars.

plotColors = function(palette, n=10) {
   colors = palette(n)
   barplot(rep(1,n), col=colors, border=colors, space=0, yaxt='n')
}

Now let’s look at the default interpolation between red and yellow in five steps. On my screen the first two colors look almost the same, although they are equally-spaced in RGB.

> pal = colorRampPalette(c("red", "yellow"))
> plotColors(pal, 5)

You can set the color space to CIE Lab by setting the parameter space to “Lab”. As you can see, the difference is huge. That’s not a question of taste.

> pal = colorRampPalette(c("red", "yellow"), space="Lab")
> plotColors(pal, 5)

Feel free to play around with that code snippets yourself. Instead of the named colors you can also create palettes between arbitrary colors by providing hexadecimal codes:

> pal = colorRampPalette(c("#FF0000", "#0000FF"), space="Lab")
> plotColors(pal, 5)

You can find the full code for this example on Github.

“Show the most important thing first!”

Not second or third, but first! And what is the most important thing to show about the outcome of an election? Who actually won.

In political systems like Germany’s, where we have no party getting anywhere near 50% of the vote, the usual one-bar-per-party bar charts totally fail to answer this most important question.

For example, in the following chart we can see the number of seats won by different political parties – but this does not tell us who won the election.

This is because the elections are not won by the party with the most votes, but the party who manages to get a majority of seats in parliament. And, with the exception of Bavaria and Hamburg¹, in Germany there’s no way to take government without forming a coalition.

The bar chart above makes it tremendously difficult for readers to figure out which coalition has won. Therefore one must calculate the total number of seats for each coalition, and compare it to the number of seats needed for a majority (which itself is the sum of each parties seats divided by two).

Humans aren’t particularly good at calculating and weighing up these different possibilities on the fly. That’s why most election reporting websites show an additional coalition view. But where is it? Right – often it is the last thing that they show, such as in this recent example from the Zeit Online:

How coalitions have been visualized in the past

In past elections in Germany coalitions have been visualized in two different ways: either as simple horizontal bar chart or as an interactive coalition calculator.

The simple bar chart as seen above usually shows a limited selection of two or three coalitions having a majority. One problem is that sometimes it would be interesting to compare those coalitions with other possible, but politically unlikely coalitions (such as CDU-GREENs in Germany).

The second problem is that excluding the coalitions that fail to have a majority eliminates valuable context information.

Do it yourself: the coalition calculator

An alternative approach is the coalition calculator. The main idea is to let the users select parties and show them wether or not a coalition of them would have a majority.

However, this puts some effort on the users, who might be checking back several times during election nights. Also the calculator only shows one or two coalitions at a time, so it’s hard to actually compare different coalitions.

The new approach: extended coalition charts

Actually this isn’t really ground-braking, but for some reasons nobody ever visualized elections this way. The idea is to show as much coalitions as possible side by side, including the politically unlikely and those who fail the majority.

To visually separate the winning coalitions from the rest I finally decided to simply pull them apart. Since I need some more space I went for vertical bars instead.

There’s a nice side effect of showing all coalitions: When new preliminary results are coming in during election nights, the visualization doesn’t show an entirely different picture, but some coalitions simply ‘changed sides’.

Since the actual total number of seats depends on the election results, I decided to label the coalitions seats with relative numbers. This means that instead of saying *coalition X has 70 seats* we say *3 seats are missing for majority*.

Coalition maps

It was a small step from here to **coalition maps**. A coalition map shows in which election districts a coalition holds the majority of votes. To indicate the coalition I decided to go for diagonal stripes, although I don’t recommend looking at them for too long :)

Actually interesting is to compare the coalition maps between coalitions. For instance from comparing the two most preferred coalitions you can see a clear divide within the state Lower Saxony.

Note: this post is a translation of this one.

In this post I want to share my findings after experimenting with different clustering techniques.

k-Means

Inspired by an example on the Polymaps website the first thing I tried was k-Means clustering. The code provided with the demo worked really well and was easy to integrate with the symbol API in Kartograph. The only parameter k-Means needs is the desired number of clusters.

Below you can see an interactive demo of k-Means clustering. You can change the number of clusters using the slider.

The main problem with k-means is that it doesn’t fix the overlapping symbols. However, since it reduces the number of displayed symbols it does improve the readability of the map. The tricky part is to find the ideal number of clusters. The fewer clusters, the more details we’re losing in the less “populated” places.

Instead of optimizing this, I decided to go back to my original idea, which is to simply cluster the overlapping symbols.

noverlap

The technique is described in this post. It takes two parameters: the tolerance controls to which amount overlapping is accepted. A value of 0.1 means we tolerate 10% overlapping of adjacent symbols. The parameter maxRatio lets you prevent overlapping of equally sized symbols. A value of 0.8 means that no symbols are grouped if the radius of the smaller symbol is larger than 80% of the radius of the larger symbol.

The resulting clustering looks much better to me. What’s nice about it is that this algorithm doesn’t affect non-overlapping symbols, so we don’t loose details outside the big cities. The name of this technique is inspired by a Gephi plugin.

Update: Just wanted to note the fact that for the noverlap clustering the maximum radius of the symbols is a crucial parameter as well. The larger the symbols are, the more of their neighborhood they “occupy”. Therefor I added a third slider in both demos.

How to use it

You can see a larger comparison of both techniques side-by-side in this example. There you also find instructions how to use the clustering in your own maps.

The reason I got to this topic is a recent post by Naomi Robbins about two opinions on the usefulness of pictographs. She reminded my of a critical article by Stephen Few, who stated that unit charts (another term for pictographs) are for kids, but not for serious information displays. My biggest complaint about his article is that he picked some of the worst imaginable examples to back up his arguments.

Let’s take a closer look at two of them:

In the first chart, each circle represents one percent of students who have been asked for their drinking behaviours. The color indicates to which category the student belongs to. In another example each stickman represent one million Americans, and the color shows whether these people would be in health insurance.

Now, both examples are really terrible infographics for many, many reasons, but for now let’s focus on the quality of the pictograms. In both cases, the authors picked icons that hardly represent their data. The whole point of using pictograms is to allow the reader to understand the subject without reading the legend or the by-text. This is what enables kids and people from different cultures or educational backgrounds to read the chart, this is what makes them universal.

So if you want to represent drunk students as icons, why not choose an icon of a drunk student instead of a meaningless circle? And instead of neutral stickmans—which could by the way be easily mixed up with Republicans and Democrats due to the color choice—one could use icons that represents people with and without health insurance.

As you probably know, there are plenty of resources where you can find icons (and I’ll add a list at the end of this post), but what if you can’t find a drunken student?

Can’t find the right icon? Ask a graphic designer!

That was exactly the problem Otto Neurath had in 1926, when he planned to create a new system for representing statistics using pictograms: ISOTYPE. And do you know what he did? He looked out for a talented graphic designer. In an exhibition in Düsseldorf, he found Gerd Arntz who was showing his wood-cuts such as Metropa, and asked him the legendary question: ‘How much do you cost?‘. Finally they worked together for the next 20 years. During that period, Arntz has drawn an impressive number of icons that influence graphic designers until now.

So seriously, if you want to represent data using pictograms/icons, you want to work with graphic designers. Unlike Neurath, you don’t need to start from scratch, but chances are that you’ll need new or at least slightly modified pictograms.

Take care about the arrangement

Besides of the choice of icons, you need to take care about how you actually arrange them. For instance in the student-drinking examples shown above, the circles are arranged in a grid of 10 times 10. In the insurance-example the arrangement was even worse, as it shows 12 icons per row. In order to find out the exact numbers, you have no other option but counting the icons one by one. That’s why both authors finally decided to write down the numbers (which is by the way the perfect indicator for poor pictographs).

Instead, what you can do is to group the icons in a meaningful way. In the following chart by Neurath, each icon represents 25,000 unemployed in Berlin. They are arranged into groups of four which makes it easier to decode the numbers. In an earlier version they used one icon to represent 10,000 unemployed, but this ended up with too many icons, so they went for 25,000.

By the way, have you notices the fact that the unemployed are faced to the right which makes them look as if they were standing in a queue? That kind of telling the story in a graphical way is the unique power of pictographs.

Let the pictograms tell the story

Let’s have a look at one of my favorite Isotype charts by Neurath and Arntz. It shows statistics about soldiers in the First World War. Each figure represents 1 million soldiers, grouped into the ones returning home, the wounded and the killed. The icons are facing opposite directions which makes clear that they are opponents returning home after war (or not in case of the killed).

Now take a closer look at the pictograms. Have you noticed that Neurath used different icons for both sides, accounting for different clothings and habits of the armies? These are the little details that make the difference!

Note that the arrangement of the groups was an important design choice, too. As shown in the following image, the chart would have been less readable if the authors had used the straight-forward arrangement (left) instead of the ‘squarified’ version (right). You don’t really need to ‘count’ the gravestones if there shown in two rows of four.

The choice depends on your goals

It’s not hard to guess what Stephen Few would recommend to visualize the WW1 soldiers: a bar chart. So let’s compare the Isotype chart to a bar chart. It tells a different story and represents the data in a more neutral way. Yes, it makes it easier to actually compare the killed/wounded for each side. But I’d say that it’s a lot harder to recall any of the numbers the day after seeing the chart.

So, of course the choice of visualization technique largely depends on the specific goals you’re trying to achieve with the chart. As explained in depth by visualization expert Noah Iliinsky, we need to differentiate at least between exploration and explanation, or in other words between analysing data and communicating data. One is needed for business intelligence, which is where Stephen Few comes from, the other is needed for education, which is what Otto Neurath dedicated his life to.

And here’s one thing we always need to keep in mind: If you want to criticise a visualization technique in general, you need to argue against the best-executed examples you can find. Can’t blame the bar chart for Foxnews.

Further reading and icon resources

• Gerd Arntz Graphic Designer — A highly recommended book about the work of Gerd Arntz, including lots of his wood-cuts, pictograms and Isotype charts.
• The Transformer: Principles of Making Isotype Charts — A small book with more details and first hand explanation about the process of transforming numbers into Isotype charts, written by Neurath’s wife Marie Neurath.
• The Noun Project — A website that collects free pictograms. In a way this project is dedicated to continue the work of Neurath and Arntz, which is to develop of visual language that can be understood around the world. The Noun Project goes beyond simply collecting icons by organizing decentral Iconathons, events where people come together to draw icons about specific topics. A great resource!
• Iconmonstr — Another pictogram website, very similar to The Noun Project.
• and of course, please check out Gerd Arntz website which shows many of his pictograms and additional resources about his work.

I was completely stunned by the clean and simple layout of this gauge chart. It shows everything I, as the driver, need to know such as: How fast am I driving at the moment, how far have I’ve been driving at all, when is it time to get a new car.

But then I realized that this tiny chart, despite its useful, intelligent design, violates some of the common rules of data visualization, so I thought it’s a good idea to write about it.

Why use a radial gauge chart at all?

Let’s face it, the current driving speed is not periodic data, so there should be no reason to use a radial layout. As we all know, humans are not as good in comparing angles as we are in comparing lengths. So why shouldn’t we use bar charts for displaying the speed?

One obvious answer is that it makes a lot of sense to re-use established metaphors. Everyone who’s driving a car knows how to read the driving speed in a gauge chart, and probably nobody ever needs to be taught reading them. Another possible answer is that we connect certain semantics to the different regions of the radial gauge layout. No need to tint the last quarter of the gauge in red, everybody knows that this is the danger zone. We don’t have similar embedded semantics in a bar chart.

Not more than three data points

According to Jorges Camoes recently published rules of data visualization, the speedometer I fell in love with isn’t data visualization at all. That is because it doesn’t show more than three data points. That’s true, there are only 3 data points I can read in the display, and, if we subtract the LCD that was added to the bottom, there’s only one number left. One single number? Do we really need a big gauge dashboard display for one number? Of course we do, because a chart never shows just a single number. More importantly, a chart puts the single number into context. If you ever had to drive a car with a dashboard like the Renaut Twingo I, you’ll never forget that difference.

For instance, in the gauge chart there are two red tick marks for important driving speed limits. Sure, I know those limits back from driving school, but I find it really helpful to see how my current speed compares to them. The other context is the capability of my car. If I’d be driving at 200km/h (which I never do), I’d instantly see that I almost reached the limit of my car.

Non-continuous scale

But now it gets even worse. As you might noticed, the speed scale breaks at 120 km per hour. Therefore comparing angles gets even harder. Without any doubt, that cannot be good data visualization! For comparison, here’s a different version of the same chart using a continuous scale:

Now we lost half of the magic of the original design. Using the non-continuous scale the tick for 100km/h, the speed limit on primary highways, sits right at the 12 o’clock position. Can you imagine driving for hours and hours watching the gauge needle standing at 11:30 as shown in the above image? It just don’t feels right, and it would always push you to drive faster.

Using the non-continuous scale allows to ‘stretch’ the speeds below 120km/h and thus makes them more easy to read. The difference between 30 and 50km/h in a populated area is more important than the difference between 130 and 150km/h on a German Autobahn. My car is a family car, not a sports vehicle. The designers probably wanted to emphasize the reasonable driving speeds, and that’s what I like most about the visualization.

When to break the rules?

So, you know, the rules are the rules, but you should know when and why to break them. Of course it is allowed to display just a single data point in a chart. And of course it is allowed to add fancy annotations to the chart wherever you like. And, yes, it is even allowed to use radial charts for non-periodic data, as it is allowed to reject a certain chart type, just because the audience is not familiar with it.

Whenever it makes sense.

Listen to Tufte and keep it simple

Of course you cannot talk about perfect charts without mentioning the great books of Edward Tufte. Especially in the book The Visual Display of Quantitative Information he summed up a lot of good advices for line charts. He argued that it’s a good idea to look at what he called the data ink ratio and showed how the removal of certain chart elements can increase its readability. For instance you don’t need to draw a box around the chart area. Also you can use the ends of axis lines to display the minimum and maximum value in the data.

Forget about the separate legend

Separate legends are the worst-case scenario in the line chart world. Often one can find the legend below the chart, or in an arbitrary order. You want to allow instant identification of the lines, but forcing the viewers to look them up in a legend takes way too much time. Instead you should put the labels somewhere close to the lines.

The great side effect of putting the labels next to the lines is that you no longer depend on fancy colors or disturbing symbols to identify individual lines. Extra points for simplicity.

Highlight what’s important

Although it is possible to tell hundred stories using a single line chart, it makes a lot of sense to keep the focus on just one story. Therefore you should highlight just one or two important lines in the chart, but keep the others as context in the background.

Baseline zero or not?

Sometimes you hear the advice that every (line) chart should have a baseline of zero, otherwise it would be “lying”. As a counter-example, here’s the (approximate) intraday stock quote data of the Facebook IPO day using baseline zero. The reason why nobody shows stock charts this way is obvious.  

It’s almost impossible to see the ups and downs of the first day of the Facebook stock. Without the zero-baseline the chart reveals much more of the data.

However, to minify the risk of confusing the readers with a non-zero baseline chart, I suggest to not draw the axes as connected lines. This way the y-axis doesn’t visually ‘touch’ the ‘ground’.

Finding a nice aspect ratio

The big advantage of line charts is that they enable the comparison of slopes, which is not easily possible in a bar chart, for instance. The problem, however, is that the perceivable slopes are highly dependent on the aspect ratio of the chart. The Facebook stock data would have looked much more dramatic in a taller chart. So which aspect ratio to chose? Some years ago, William Cleveland suggested a technique called banking to solve this problem.The core idea is that the slopes in a line chart are most readable if they average to 45°. In 2006, Jeffrey Heer and Maneesh Agrawala continued the work of Cleveland and described 12 different banking algorithms. I used one of the most simplest of them, the median-absolute-slope banking.

Finally, here’s what the Facebook stock chart looks like after banking. The curve looks less dramatic now, but is still easy to read.

The problem with banking is that sometimes you need the chart in a certain aspect ratio to fit into a page layout. Especially if banking produces portrait sized charts. But why not let the optimal chart ratio define your layout? For instance, you can put the additional information to the side of the chart. Remember that the main goal of banking is to increase the readability of the line slopes. In the following example, the slopes for Nuclear and Renewables would have been much more difficult to see, if the chart would have been ‘squeezed’ to a landscape aspect.

Turning best practices into actual tools

At the end, I am very happy to say that these best practices won’t remain gray theory in research papers. Everything I mentioned will be integrated in the upcoming release of Datawrapper, which I already used to produce most of the examples in this post. Please follow @datawrapper if you want to keep up-to-date with the project.

If you have further suggestions or recommendations for line charts, I’m looking forward to read your comments.

With Twitter we now we have a social bookmarking system that works perfectly on the input side. Not only do I tag my links but I also describe in a few words what the website is about, and why it is worth sharing. But when it comes to getting the information out of Twitter, things start to get ugly. Have you ever tried to find a link you retweeted months ago? I did. The Twitter search won’t help you since it is limited to the most recent tweets. The only thing you can do is to scroll down your timeline and click the ‘load more’ link until you find what you look for.

Enough of the problem, let’s come to the solution. I wrote small python script that stores my tweets and favorites in a local sqlite database. It does so using Mike Verdone’s wonderful Twitter API for Python. I installed the script as a local cronjob that runs every hour so my database will remain up to date all the time.

Then a second script allows me to perform simple searches on that database and writes the output to a html file. Finally I integrated the search into Alfred, a spotlight-like tool for making my life easy. Now I just type “tweets foo” in Alfred and the search result html will be opened instantly.

Here’s a demo video:

While at hacking I also built two special modes: Typing “tweets favs” will simply output all tweets that I marked as favorites and typing “tweets March 2010″ will return, well, all tweets from that month.

Here’s the source code of the two scripts and the Alfred script. Just make sure to enter your own Twitter name and create some OAuth keys for the script.

https://gist.github.com/2349453

Last remark: I’m pretty sure that there’s some amazing web service out there that does the same for you without the need to hazzle around with python scripts. However, I haven’t checked them out since I like to access my tweets offline as well (for instance when sitting in a plane or train).

This is going to be a quick run-through the creation of the latest Kartograph showcase which is a high res vector map.

Select your map projection

I really like the idea of starting the map creation process with choosing a map projection. As mentioned in my last post, the projection can be seen as a very crucial point of every map. It allows you to define the perspective on the geography. In this showcased I used the tilted perspective projection, looking from Florida to New York.

The new visual map configurator shown in the above picture not only gives you a preview of how your map will look like, but it will also give you a nice template for the JSON configuration Kartograph will use to generate the map.

The next step is to tell Kartograph were to cut the map view. This time I will use the points mode which allows me to give Kartograph a set of coordinates that I definitely want to be included in the map. You can add some padding, too.

"bounds": {
  "mode": "points",
  "data": [[-70.5,41.2],[-90.1,32.1], [-72.8, 34], [-70.8, 31.5]],
  "padding": 0.02  // defined as ratio of total width
}

Since this feature is not included in the visual configurator (yet?) it’s up to you to experiment with some coordinates to find out I nice bounding box. Finally I ended up with something like this:

Define outer Latitude/Longitude range

Since our map only shows a small part of the world, we can speed up the map creation process by forcing Kartograph to skip every geographic feature that lies outside a given lat/lon bounding box. To select the bounding box I used the nice OpenStreetMap export feature.

The limits for latitudes and longitudes are then added in the bounds.crop property. The format is [minLon, minLat, maxLon, maxLat]:

"bounds": {
 "mode": "points",
 "data": [[-70.5,41.2],[-90.1,32.1], [-72.8, 34], [-70.8, 31.5]],
 "padding": 0.02
 "crop": [-90.85, 28.12, -65.69, 51.9]
}

Of course, to find out which feature lies inside or outside the selected bounding box, Kartograph still needs to run through all the features in the shapefiles. If you deal with really huge shapefiles (like this 100mb shapefile containing 167.000 forest polygons) a better idea would be to filter the data directly in the shapefile. The open source GIS software QuantumGIS makes this really easy:

Add some nice layers

At this point all what’s left to do is to select a nice set of layers that you want to include in your map. I ended up with like ten layers coming from Natural Earth and VMAP. You can give the layers some basic styling to make it easier to work with the raw map output in Illustrator.

"layers": [{
  "id": "trees",
  "src": "shp/custom/useast/trees.shp",
  "styles": {
    "fill": "#b1bfb1",
    "fill-opacity": 0.4,
    "stroke": "none"
}]

Here’s how the map configuration finally looked like.

Refine in Illustrator

After finishing the map configuration I loaded the generated SVG (7 megabytes) into Illustrator to add some labels and refine the colors.

And here’s the final result:

Related links

• Kartograph.py API docs

Over the last two years, cartography has drawn my attention from time to time. In 2009 I started my work in the field by porting the PROJ.4 library to ActionScript. My first notable interactive map application was a world map widget for the Piwik Analytics project, which is in use until today. It was born from the need to have a simple world map that is lightweight, easy to use and completely independent from external map services like Google Maps.

A lot of things happened in the field since then and some cool mapping frameworks have been released. Google Maps keeps innovating and gives people lots of reasons to use their service, even on a commercial basis. But still one thing seems to never change: the Spherical Mercator projection.

Why should we care about map projections at all

In contrast, data journalists are nowadays limited to just one projection. To illustrate the journalistic dimension of this limitation I will now show you three maps of the same geographic area. The first uses the well-known Mercator projection:

The Mercator map looks neutral, clean and… boring. In fact, the projection shows the earth as an cylinder shot from an infinite distance. You really can’t distort a view on our planet much more. Note that the area of Spain looks as big as (and maybe even slightly smaller than) Germany. In contrast, the next map uses an equal area projection.

The curved grid lines indicate that we’re living on a spherical planet, but still we are looking at it from an infinite distance. Looking at the equal-area projection, one would now say that Spain is slightly bigger than Germany (in fact it is 141% the size of Germany). You can easily imagine scenarios where true areas are really important, say if you want to show the extend of devastation of the latest environmental disaster or something..

And finally, here’s the last shot which shows the same geography using the tilted satellite projection:

Hello Kartograph

Since I know that it’s kind of unfair to propose new awesome features while knowing that almost nobody is able to use them, I decided to turn my ideas into code. For 4 months or so I had been working on a new mapping framework which I finally named Kartograph.

Here’s a bit of the rationale behind Kartograph. Most notably Kartograph..

• ..allows to select and fine-tune the map projection, which is like the fundamental equipment for telling stories with maps
• ..ships with the tools needed to easily convert open geo data (shapefiles, kml, geojson) into interactive data-driven maps
• ..gives its users complete control about what to include in their maps and what not to include.
• ..puts a focus on reliable data visualization techniques.
• ..does not rely on hosted (and costly) mapping services like Google Maps or MapBox

Of course, there is a lot of work left, and I’m currently looking for some way that allows me to continue the work on Kartograph for another two or three months. In the meantime I also plan to release a new version of the world map widget for the Piwik dashboard, which was kind of the initial reason for starting to work on the library.

Now, I’m really curious for your feedback about Kartograph. Do you think it is worth the effort? Do you know of any existing library that can do the same? What are the killer features you would like to see in a modern vector mapping framework?