In recent days, a conversation has been renewed about the prospects for an “Orbis-in-a-Box” platform (OIB) for simulating historical movement across multi-modal transport networks. The idea holds great interest for me, and this post is a hasty “my two cents.”
Context
ORBIS: The Geospatial Network Model of the Roman Empire (ORBIS:Rome) was initially launched in May 2012 after something less than one year of intense development. A major upgrade to the site was completed in 2015 by its lead developer, Elijah Meeks. At initial launch, the number of visitors to the site wildly exceeded the project teams’ expectations, and six years later there are still on average 8-9,000 distinct user sessions per month. Although there are peaks and lulls in traffic, that number remains remarkably consistent. Walter Scheidel was the project’s principal investigator, and several of his students made substantial contributions. My own role was developing the front end for Version 1 and serving as something like a ‘geographer sounding board.’ Complete credits are found in the “About” section of the site.
In the Fall of 2012, Walter Scheidel hosted a mini-conference at Stanford to discuss the results of the project and speculate about next steps to be taken, if any. At that meeting, and in many settings since, all of the project team have heard inquiries along the lines of, “how can I make an Orbis of _____?” I think it’s fair to say Walter, Elijah and I all thought that was a commendable goal, but there wasn’t the time or funding context for it.
Not that I didn’t try: in 2015 I led the authoring of an NSF proposal titled “The Orbis Initiative,”” submitted by Stanford Libraries, that would have produced, effectively, a generic OIB platform. Although the proposal received high marks from reviewers, it fell short and we didn’t re-submit. In 2016-17, I turned my attention to another aspect of historical geographic movement: modeling journeys, named routes, and flows — specific and aggregated events _occurring on_ the roads, rivers, and sea lanes of multi-modal transport networks. Lex Berman, Rainer Simon and I developed a temporal extension to GeoJSON (GeoJSON-T, now GeoJSON-LDT) and I built a pilot web app, Linked Places to test it out against several kinds of data.
I still firmly believe an OIB platform would be used by many (?) historical scholars and be a valuable contribution. Apparently others feel the same way. As Maxim Romanov has recently suggested, maybe we can collectively take some steps in that direction, absent (for the moment) a big funding source.
The Use Scenario, aka User Story
We don’t have to make one up — the al-Ṯurayyā Project, led by Masoumeh Seydi (U Leipzig) and Maxim (U Vienna) could readily become a first user of OIB. But to state it in more generic terms:
A team of scholars, in the course of researching a particular region, period and themes, has developed a set of historical network data, and wishes to simulate movement along that network to better understand related events and historical processes of the study area. The data consists of named places (nodes) and route segments (edges, typically unnamed). Segments have been assigned costs associated with traversing them by various modes (e.g. vehicle types), possibly with seasonal variations. The costs are best estimates drawn from primary and secondary sources.
The team arranges their data in the format specified by the new OIB platform, downloads the OIB software from GitHub, and stands up an instance in their local development environment. They fill in several parameters in a configuration file specific to their project, including project title and data path, fire up a local web server, and navigate to a new graphical interface to their network. After making numerous adjustments to configuration parameters, and possibly some customizations to code, they deploy their OIB instance to a cloud server, route a domain name to it, and tweet out an invitation for people to use it.
Simple, no?
From Here to There
Some big obvious questions arise from this scenario, including: What functionality must the web interface have, and how generic can it usefully be? That is, what questions are being asked? What data will be required, and how readily can it be developed?
Regarding data, ORBIS:Rome required modeling maritime movement across the Mediterranean, part of the North Atlantic, and the Black Sea. This was enabled by Elijah’s inspired creation of a sea mesh. Assuming this method stands up as something to replicate, other parts of the world would need other meshes. Travel across larger bodies of water were really constrained by seasonal trade winds, as I’m learning reading “Pathfinders: A Global History of Exploration” so global meshes may be unnecessary.
Regarding functionality: in ORBIS:Rome, seasonal segment costs in terms of effort and dinarii are “baked in” — should OIB permit adjustment of these values by users (not only authors/publishers)?
How to Begin?
A few possibilities:
- Launch an OIB Working Group of Pelagios Commons? The deadline for this years’ mini-grants is Wednesday(!)
- Collectively decide upon a useful first phase of effort that can be realistically accomplished given time and money constraints.
- Get that started at a hackathon, pre-work for which might include: surveys of existing ORBISs:Rome code (or not!)
- The algorithms and data models of Orbis:Rome are not well documented (costs extra, no time!); a pseudo-code representation of them might be a useful starting step. Its PHP code could be ported to a more modern language/platform, and undoubtedly refactored. Fresh eyes by other developers would certainly lead to improvements.
- A survey of the existing functions, followed by a group assessment of how generic they are, as well as priority v. effort ranking. The same for graphical elements and widgets.