Media archaeology with Rand McNally’s Trucker Tools (2001)
One of the threads I’m trying to work into this dissertation has been the specific role of geospatial softwares in the “logistics revolution”—the period in the 1960s and into the 1970s where logistics as a practice and field of study is popularized and standardized through new quantitative methods, the standardization of the shipping container, and deregulation of industries core to logistics. It seems pretty obvious that mapping or routing would play some role in the “quantitative methods” available to people in logistics, but I had less of a sense of who were the players in developing and productizing those methods and what that software actually looked like.
In retrospect, it should have been obvious which company would play a major role in developing trucker routing and fleet management technologies: Rand McNally. The map publisher’s print products had a long history of being a trucker’s best friend, while their printed editions of Household Goods Carrier’s Bureau Mileage Guides (basically, a thing used to optimize distances between places to calculate shipping costs) were a scheduler’s best friend. As a big incumbent they were also in a position to acquire nascent software firms working on routing software—which seems to have emerged from a mix of academic work in operations research, urban planning, and transportation building on linear programming. In 1980, Rand McNally acquired the firm Transportation Data Management (TDM), which is a very annoyingly generic name. Rand McNally-TDM made a software product called MileMaker, and later IntelliRoute, for the trucking market.
Today, a lot of what you’ll find on eBay for MileMaker are hardware/software system combinations: GPS receivers with software optimized for routing options unique to trucking. This is maybe obvious, but the reason truckers can’t just use Google Maps to determine their route is because trucks can’t go everywhere that consumer vehicles can—they are too tall for some overpasses, for instance, and if the truck is carrying hazardous materials regulations in certain areas might forbid them from certain roadways. (Side note: did you know that milk is technically a hazardous material in transportation regulations? It’s true!)
However, I was lucky (?) enough to spot a free trial CD-ROM for a 2001 MileMaker/IntelliRoute product on eBay called Route Tools (Professional Driver edition).
This software probably came out right before or just as Selective Availability for GPS was ended, so it makes sense that it’s a desktop application. Today there’s a whole sector of custom tablet-type devices for truckers with built-in GPS and routing software, but 2001’s RouteTools is more of a pre-on-the-road tool than an on-the-fly one. I spent some time poking around this software to see what I could learn from it.
User Experience
I expected this to be a hassle to boot up but Ramsey tried just loading it into a Windows partition on his Linux machine and it just…worked. Forgive me Windows backwards compatibility, I was unaware of your game.
Unfortunately, the software really didn’t seem to know what to do with being on a monitor bigger than 800 pixels. It looks like the application had preset raster maps of North America at some standard monitor sizes that it expected the software to load in, and then the road layer was drawn on as a vector file upon launch to fit the width of the application window. Which meant when opened on a big modern monitor, the map looked like this:
If you zoomed into the map (done, of course, with a button at the top) the map rendered more on-the-fly, it seems? But it’s not clear to me why a map was part of the interface at all because 1) it’s not a very detailed map and 2) the interface for generating a route didn’t actually produce a map, just a general list of directions.
The geocoder only covered city-scale locations and was fairly picky—most searches didn’t go very far until I’d added a comma. This structure for generating a route doesn’t by default include backhauling (the part of a truck route where the vehicle goes back to wherever it started; usually you want to fill that with more deliveries if you can so the drive isn’t just burning money). You could probably add a backhaul route into a plan (so like all the stops on San Diego to Houston, then a bunch of stops for Houston to San Diego) but it didn’t assume that the truck had to go back to wherever it started.
I can see two possible reasons why the map didn’t render the routes:
Error: it actually was supposed to render on the map but something happening behind the scenes was fucking that up (maybe the window size issue was causing problems for rendering?). There’s also a dataset that was supposed to be downloaded from the internet that absolutely wasn’t loading—maybe a server was supposed to spit out route generation too?
On purpose: for one thing, what’s the truck driver using this software going to do with this map generated on a desktop computer? Print it? At what scale? How much ink would that use up? The list of directions produced by the software would probably be good enough for someone who mainly needs to follow highway signage.
A reason I think this could go either way is that there doesn’t seem to be a tool for exporting the map in the first place (maybe that’s only available if you upgrade from the free trial?) and there is a tool for adding little pins to locations, which would suggest that any additions to the map are supposed to be user generated:
But there is also a locally stored dataset of truck stops that, in theory, should have been able to load onto the map!
This was a really fun dataset, incidentally—look at all the little details about specific truck stops!
I wonder if the data on truck stops was collected by Rand McNally personally in some kind of elaborate truck stop census. Imagine having to verify all of this!
Since this is described as the “Professional Driver Edition” I am guessing that the imagined user of this software would maybe be an owner-operator (basically the gig workers of trucking, a worker category that exists as a result of industry deregulation). There’s also a “Small Fleet Owner” edition that has added features for routing hazardous waste material, fun.
Looking at data files
A nice thing about living with a Linux nerd who enjoys reading byte code is when you ask them if they think it’s possible to get into the files on an old Windows CD-ROM their answer is “sure, that sounds fun.” Thanks Ramsey! The main thing we were interested in were the .cab files (a Windows file compression format—it’s short for “cabinet”, which is cute). I wanted to see whether any of the data available in the application was stored in plain text and could be converted into a modern geospatial file format.
A lot of the files were unfortunately just binaries—i.e. not really useful to a data scavenger like me—and I’m still puzzling over what some of the plain text files are supposed to be. Like this one:
We realized after staring at this insane layout for a moment that this file was made expecting a specific window size:
But I have no idea what this is supposed to be. Names of roads? And maybe road classifications? Edit: thanks to Peter on Bluesky who identified this as a database of fixed-length 16-character road names.
We did find a plaintext file of all the truck stops, which we figured out was formatted assuming some maximum character count for each value rather than broken up by tabs or commas:
The truck stop data also had point coordinates, which adds to my suspicion that they were supposed to render to the map and weren’t because of a rendering error. In a funny example of data storage efficiency, because all of the longitudinal values would necessarily be negative since the map only covers areas north of the Equator, the file just didn’t bother storing the negative integer. I’d like to eventually get around to parsing this file so that it could be turned into a nice little geojson, though I recognize there isn’t a ton of demand for data on truck stops of North America circa 2001.
Also, the original pre-baked base map images were in there which is how we figured out that the application expected a window size of no bigger than 800 pixels:
MileMaker is still in operation today—they have a nice little product demo on their website that shows a much slicker web-based interface than the 2001 tech I tried out. Rand McNally has another division that does custom hardware for truckers, which look like basically tablets with GPS receivers and custom software. The main things I’m trying to get a better grip on with this history are:
- The public/private dynamics of its development: I’m not sure whether specific firms emerge from an academic lineage. Were people studying this stuff in school and starting their own microcomputer based software companies or were companies happening independent of/in parallel to that research?
- Deregulation and software development: experiments in trucking software predate the 1980 Motor Carrier Act that deregulated much of the industry in the United States, but it does seem like routing software for trucking has an obvious appeal to newbie owner-operator truckers less steeped in the culture of memorizing routes and boasting about never needing a map. How, if at all, did deregulation affect software development and adoption?
- Pre-and-post-civilianized GPS comparison: how did this change product development? How did it change trucking? A wild thing gleaned from trucker forums is that the HHG mileage guide remained (remains?) a primary tool for estimating cost and rates for shipping, which in turn shapes how much a driver gets paid. In a pre-GPS era of mostly mechanical odometers I can sort-of see how being plus or minus some number of miles could be fine but in a time of super-precise location measurement, this seems like an easy way to short-change drivers who go over the HHG mileage estimates.
If you have stumbled onto this blog post and are rolling your eyes at how little I understand this sector, please help me out! I would love to talk to you.