On July 18-20, I will join several other “interested digital humanists with an inclination for coding” gathering at the University of Vienna to consider what a generic version of ORBIS: The Stanford Geospatial Network Model of the Roman Empire (ORBIS:Rome here) could or should consist of, and to begin creating it. Several people have expressed interest in beginning a “Silk Roads Orbis” as a first example. I will participate in this effort and I’ve written up these notes to clarify my own thoughts. As the front-end developer for ORBIS:Rome v1 and a witness to v2 development, I may have some helpful insights 🤷🏻♂️.
Simulated routes over a network vs. “modeling travels”
The idea of Orbis-in-a-Box has been one guiding thought for this meeting, but the announcement for it is titled “Modeling Travels in History.” ORBIS:Rome was all about route simulation, whereas “modeling travels” suggests particular journey events. The time costs associated with network segments should be derived in part from historical accounts of actual travel, but in my view these are two very different undertakings.
Apart from ORBIS-like route simulation, I am keenly interested in modeling events of geographic movement (see the Linked Traces pilot application). In the conceptual model and schema I developed for that with Rainer Simon and Lex Berman, historical movement data falls in three categories: journeys, named historical routes, and flows. Journeys and flows are eventive data; historical routes are courses of travel taken routinely over time by unspecified travelers (sets of segments).
Breaking Down ORBIS:Rome for OiB
The following outlines some system functions and related components.
The three principle functional categories in ORBIS:Rome are
Route finding: one-to-one least cost path
Given two places (a.k.a. sites, nodes), calculate the least-cost path for a simulated journey between them across a multi-modal network of roads, paths, rivers, and maritime routes. Journey cost is the sum of weights for its network segments (edges). Segment weights are derived from distance and some combination of “friction” estimates drawn from modern topography and historical sources. Results include duration, distance, and dependent on available data, a derived monetary cost of transporting commodities or people across it. Additional parameter choices for ORBIS:Rome include: season of travel, transport mode (vehicle, animal, foot), and network modes (road, river, open sea, coastal).
Cartograms, contour maps, and regions: one-to-many paths
The k-dijkstra algorithm allows very rapid calculation of costs between one node and many others. Results – ‘fields’ of point values in a large area – can be used to create several geospatial analytic products. Cartograms substitute time or other cost for distance, and distort maps accordingly. Contour maps show bands of roughly equal values for some value associated with point locations; in this context, time or expense for travel between a given point and all others in an area can produce isochrone and isodapane maps, respectively. Given several “start” points, one can also compute regions with clustering and Voronoi algorithms.
Application Programming Interface (API)
The internal API for ORBIS:Rome has not been documented for external access, but for OiB it could be. The number of allowed parameters may determine its usability. You can see what queries ORBIS:Rome generates dependent on UI choices, using the “Network” function in browser developer tools consoles. For example, calculating a route between Constantinople and Jerusalem with various parameter values looks like this:
http://orbis.stanford.edu/new_route.php?v=foot&m=7&s=50129&t=50213 \ &tr=0&ts=0&p=0&ml=road,coastal,upstream,downstream,overseas, \ ferry,self,ferry,transferc,transferf,transfero,transferr \ &el=999,99999
It returns a complex JSON object that front-end code parses for display.
- Places (nodes). Point data for settlements and other related network nodes (e.g. coastal promontories).
- Segments (edges). LineString geometry for paths; in ORBIS:Rome, principal segment (path) types include road, river, ferry, open sea, coastal. These are further subtyped to differentiate associated weights, which have been pre-calculated: e.g. river segments include upstream, downstream, fastup, and fastdown subtypes. There are also logical transfer segments to allow associating costs with switches between modes (e.g. road to ferry). The main edge table has 53,539 rows, for 7740 distinct node pairs. Arriving at plausible segment weights demands intensive historical research and/or geospatial analysis.
- Segment weights. Segment costs can vary according to season and direction (upstream/uphill vs. downstream/downhill). We may wish to factor elevation change into weights. For ORBIS:Rome, historical sources indicating travel times between places were relatively sparse compared to what may be available for later periods.
- Segment restrictions. In ORBIS:Rome, a number of segments are “restricted” – omitted from some calculations – in various circumstances, including “no go” in certain months, or not feasible for some transport modes.
Some data considerations
Temporality. Networks change over time, sometimes significantly. So do vehicle types and capabilities. Travel across the broadly defined terrestrial and maritime Silk Roads occurred over roughly 1500 years. The ORBIS:Rome network “broadly reflects conditions around 200 CE.” How should a generic OiB allow implementations to account for network change over time? With temporal attributes of nodes and edges? With discrete snapshot data subsets? Either?
Granularity. Data density for particular regions within a given OiB scope may be more or less sparse. This variation can affect results significantly. What should be best practice recommendations for this?
Resolution. Vector MultiLineString data can be created at various resolutions. The distance of a given path between two places will reflect how articulated the relevant segment linestrings are. Great variety in resolution can result in misleading results.
Paths versus simple edges. Edge data for ORBIS:Rome is “geographically embedded.” That is, it reflects approximate courses of roads, rivers, etc. It would also be possible to use simple edges that are “partially embedded,” with geometry fixed only at start and end, and to assign weights reflecting distance (among other things), but not representing actual paths. Should this be an option?
Software package design
How will users implement Orbis-in-a-Box for their particular study region and period? What “user stories” or “use scenarios” should drive development?
Ideally (?) a user could a) clone an OiB repository, b) install a relatively few dependencies on their system, c) make some edits to a configuration file for project-specific settings, including data source, d) run a local HTTP server on a specified port, and e) navigate to a GUI with a number of features that allow them to query and visualize their dataset. Once the application looks right and is giving proper results, it could be deployed to a public web server.
What are the features for a v1 of OiB? for a v2?
 Short for ORBIS: The Stanford Geospatial Network Model of the Roman Empire (http://orbis.stanford.edu)
 Cf. “Creating an Application like ORBIS” in https://onlinelibrary.wiley.com/doi/full/10.1002/bult.2015.1720410206