Datasets and Maps
About Maps for Books

There’s nothing like a book with a good map in it.

And conversely, there’s nothing like a great book about a journey without a map in it—or when the book has only a small map without much detail. If you are a geography-lover like me, you find yourself only a couple of pages in, yet already reaching for atlases. All too often the atlas is insufficient and you wind up trying to find out the location of a place on the web.

It's satisfying to find out where these places were, to locate where Kudja is (or was), or where the Çoruh river flows. But at some point it becomes clear that it would all be much better if all  the places from the book could be brought together on one map, a specific map that can be consulted for this specific book.

Such a map needs to serve multiple purposes. When I read in Charles Camsell’s Son of the North that in 1896 he travelled up the Liard River by dog sled and came to the steaming hot springs, I want a map that will show me where that is—and, on top of that, how I might repeat his journey today. It’s all and well to make a map that shows the landmarks mentioned by the writer, but we also want to know where these lie in relation to modern landmarks such as towns and highways.

The maps and datasets collected here have been made by me at different times, with different goals in mind. Some are merely geographic data—a table of names with latitudes and longitudes—perhaps with a static map image. The maps always begin this way because the answers to geographic questions initially just create a pile of data. In this case, if you want to explore further, you will need to download the geodata yourself, and pull it into Google Earth or QGIS or an online mapping service like GPSVisualizer to view it. It's not as hard as it sounds.

In other cases I have built entire web maps that you can explore online (and download the geodata as well if you wish). Sometimes photographs have been integrated into these datasets. Wherever possible I have provided a list of references; in other words, how I know where these places are. By consulting the references (which are usually other maps) you can confirm for yourself where these places are.

Researching where these travellers have gone unearths a great deal of information: about what towns used to be named, about where international borders used to be, and about the other travellers who were in the area at the same time. I don't like to use the word explorers: we know that they rarely explored or discovered anything that was not already familiar to the local people. What they did that was different was to publish about it later. I like the term writer-travellers.

Sometimes the geodata includes the routes the writer-travellers took, to the extent that this can be pieced together from the text and perhaps from a map they left behind.

Some general words about data formats
The ideal geodata format allows you to record multiple fields for each point, line or polygon, and yet is easy to send around (e.g., one file) and can be read by virtually all the relevant software. This format doesn't really exist.
  • Shapefiles are popular because they fully support multiple fields per object, and can be read by most GIS software, but shapefiles can only hold one kind of geometry (point, lines or polygons) and consist of five or more related files.
  • KML (Keyhole Markup Langauge) is popular because virtually everyone can read it and it's a single file that can hold multiple geometries. Unfortunately, KML usually only allows two fields, a name and description, for each object. (Note that there are extensions to KML (<ExtendedData>, for example) that allow more attributes for each object. Such fields can be imported into GIS, but are not editable within Google Earth.)
  • CSV (Comma-separated values) is a plain-text format that is popular because virtually everyone can read it, and it's a single file. But CSV is really only good for points: putting lines or polygons into it  is cumbersome.
  • There are some more recently-invented single-file, multi-geometry formats such as the ESRI geodatabase and the Geopackage, but at this point these are still restricted to a few pieces of software.

So, some compromise is involved with every format. I tend to distribute data in CSV, KML and shapefile.