One of the features of ORBIS that I’ll be demonstrating next Wednesday is this dynamic distance cartogram, which is on Github as a gist and can be seen using bl.ocks here. It’s been written in D3 and uses a few pre-generated cost paths through the model to provide a cost to ship grain to Rome from the various sites around the Roman empire. The buttons recenter the network on four different cities–Rome, London, Istanbul and Antioch–and distort the position of the rest of the sites so that their distance reflects the cost in denarii to ship a kilogram of grain according to network path cost based on the Edictum De Pretiis Rerum Venalium.
The code is messy and the math is very simple. You need no more than the Pythagorean Theorem to distort geography based on a fixed distance like the cost to ship a kilogram of grain from many points to one. But the effect is very useful. Unfortunately, Github gist doesn’t allow me to post all of the data files (which should, in all honesty, be a single data file with multiple columns, and will as soon as I find the time) and so you can only see the cost in Winter and not be able to compare it to the speed to travel.
Given that this has become a bit of an admission of creaky code, some other things that need to be tightened up are:
- Use geoJSON instead of JSON for the geography paths in grey
Reduce the decimal places in the data file (if only there was a minify tool that had a “bad geographer” setting)- Move the label-click event from the labels to the actual nodes
- Add lines to indicate the roads, rivers and sea routes that are connecting these sites
- Find out more things that are wrong with it…
We’re supposed to be more open about our development process in digital humanities research, which not only means using open source but actively exposing processes (and problems) and acknowledging just how much of a hack something is. Left out of the various arguments about how we should learn to code or not is the fact that much of the increase in the popularity of coding has occurred because the languages, libraries and tools have grown so accessible that even a schmuck like me can now write interesting little pieces of software. The price we pay is the increase in hacks and inefficiency that makes LISP programmers cry themselves to sleep.
Being a programmer, at least to this degree, isn’t much like being a programmer in the old-fashioned sense. Ugly, unoptimized code like that which I’m not-so-proudly showing here runs quite well on modern machines with too much power and incredibly slick JavaScript engines. It wouldn’t scale to supply the needs of a fortune 500 company, nor will it win any prizes for its efficiency (or run on an old version of Internet Explorer, for that matter). However, it does accomplish the goal of representing how the size of a historical world system is dependent on the reason for travel and the time of year when that travel takes place. I’m really proud of this cartogram, even though it still needs work, but I’m even prouder of the fact that I’m able to bring it to bear in the expression of some scholarly claim. I’d like to be a good coder, but I’ll settle for writing bad code to address interesting problems.