Finding ones way around Buenos Aires in 1870: a proof-of-concept for routing with OpenHistoricalMap data

A critical point about using OpenStreetMap technologies in OpenHistoricalMap is that we should get lots of useful tools for free.

Plaza de Mayo 25, Buenos Aires in the 1860s
Source: Wikimedia Commons CC-BY-SA

We touched on this point during our end-of-year Google Hangout. In particular Karl Grossner. wanted to know more about how one might use the data for routing. Karl is part of the team behind the awesome ORBIS project at Stanford, which allows routing across Europe during the Roman Empire.


Karl had two basic questions: the first was "How might one do routing?", the second "Is OSM only city scale?" I will return to at a later time. Although it was easy to say, "yes of course we can do routing, there are lots of OSM tools", it's much better to demonstrate this in practice.

Now I should add I really no nothing about the practicalities of OSM routing tools. Although I use OSM routing, it's never been something that I've been particularly interested in, and there are loads of people who are interested with much better technical savvy than I have. (I would love to be able to generate isochrones, but have usually given up because all the approaches I've looked at seem to require writing more code than I want to).

Example of a historical isochrone map
Public Transport in Melbourne, Australia 1910s
Source: Wikimedia Commons  CC-BY-SA

Therefore I set out to build the simplest kind of demonstration of routing with OHM data and OSM tools.

The first consideration was that any routing needs to offer a range of different transport modes: most historical scenarios prior to around 1920 don't work if we only use one mode as many tools do today. This ruled out routing engines which only use contraction hierarchies, notably OSRM. In practice, at least for city-scale routing during the 19th century, if would be nice to use a multi-modal approach.

I therefore started with graphhopper, which although by default uses contraction hierarchies does allow alternative methods. Installing graphhopper was very easy once I'd sorted out Java environment variables. A particularly nice aspect of the install is that getting a web server running on local host is totally painless. I used the Berlin example in the demo to test everything was working, and then extracted the 1870 Buenos Aires data from OHM using Josm, and compiled the routing graph.

I had a couple of false starts accessing the graph via the web application, but once I could search for streetnames then I got markers on the map which I could re-position. Then I got sensible routes. The nice example is anywhere which is more accessible from the Plaza de Mayo via one of the diagonals, such as the Obelisco. In the first iteration I just used the graphhopper web page unaltered, so that the route was displayed with modern OSM data. I could see that everything was working because routes stopped at the edge of the historical data, and roads which did not exist then were not used.

Basic routing demo with 1870 data overlaid on a current OSM-derived map of Buenos Aires

To make the demo a bit more convincing I needed to tweak the leaflet javascript which populates the layer selector. This was easy, finding the url for OHM tiles was what took me longest to sort out. I plan to use the minor changes I made to the graphhopper javascript as a way to learn more about GitHub.

As above, but with OpenHistoricalMap tiles

The problem with graphhopper is that it is a library, and in particular adding new transport modes and weightings seems from reading the documentation to require writing java code. So whilst this is perfectly feasible, its way more than I want to try and do at this stage (particularly as I would be on the steepest part of the learning curve). This suggested to me that at least initially I needed something where routing profiles and weights are configurable as settings.

Other things which were apparent:

• Search. The standard way which online routers approach search is to use a different (although often more or less tightly federated) database. This becomes really obvious when using historical data, when the search finds things which dont exist! We know this is an issue, and indeed a lot of work both in Wikimaps and OHM over the past year has been concerned with how one builds time sliders to assist in search. However, seeing it in a browser really brings home that the current approach is awkward to say the least.
  
  There are other useful starting points, such as the Library of Congress gazetteer built by Topomancy LLP, the code for which is now on GitHub, Pleiades, etc. Ultrazool's recent mailings to the talk-historic list give a good overview of state of the art.
• Default Cartography. Using the standard Mapnik stylesheet from OSM is neat. It enables one to look at the past from a modern perspective, BUT it is not only heavily influenced by the structure of the British transport network of the late 20th century, but it is naturally car-oriented. Ultimately OHM will need something slightly different; almost certainly more muted (overlays will be important), and perhaps with indications of data quality (is a road conjectural, found in traces, etc).
• Routing is a great QA tool. Using the city stripping method one may not update the source data to reflect the changed date. In fact I did this with the Buenos Aires data: I failed to change a few highway=pedestrian ways to highway=residential. This was immediately apparent when I first tried out the routing. Equally it was trivial to fix. It does point out that there is real scope to build first-cut vector models for particular places and periods, and through provision of suitable tools enable people familiar with the period to validate the model.

Routing for 1870 Buenos Aires using OpenTripPlanner

As I am interested in multi-modal routing for Buenos Aires (the structure of the city is heavily influenced by the railways and the tram network was incredibly dense from around 1865 onwards), I also tried with OpenTripPlanner. The experience here was similar to graphhopper; installation was quick, and the web application ran 'out-of-the-box'. It took time to get the compiled graph in the right place, but StackOverflow helped. Once again altering the weights and adding other modes seems to require more effort than I plan right now. A bonus would be if anyone can take old timetables & convert them to GTFS format, which would add a real neat twist to historical routing.

Lastly I tried Routino. The big advantage of Routino is that handling of OSM tags, adding new routing modes and changing weights can all be done through changing XML files. Again it installed easily and creating a routing graph also was easy. The slight downside is that getting a web page up and running involves more work. I haven't done this yet, but this seems the best route forward in the short term.

All in all, its nice to show that exactly as expected routing worked.  I also learned a bit about the routing engines above. My next step is to get a Routino web page working. Next up: looking at historical routing will be Roman roads in Great Britain (to look at routing at non-city scales).