Geotagging at SFO Museum, Part 8 – Old maps

This is the eighth of an 11-part blog post about geotagging photos in the SFO Museum collection. In the last post I wrote:

Just like the example in the last post we’re still just writing data to a terminal window but this time we’re writing different data. In the next post we’ll describe how to publish that data remotely.

We’ll actually get to that shortly but first we’re going to take a surprise detour back to the map itself. Here’s why:

The WhosOnFirstGeotagWriter writer that we talked about in the last post was the first step towards building an SFO Museum specific geotagging application but it turns out to be generalizable enough that it could be used by any project that reads and writes Who’s On First data.

We’ve since built a third geotagging application that sits on top of the first two (go-www-geotag and go-www-geotag-whosonfirst) that is tailored exclusively to the needs of SFO Museum. Following the naming conventions we’ve adopted to date it is called go-www-geotag-sfomuseum and I’ll write more about it in the future.

What’s become clear as we work through geotagging photos in the SFO Museum collection is that it’s very useful to be able to geotag things using a map from, or near to, the same year that a photo was taken. The facts on the ground change often and fast enough at SFO that it can be hard to make sense of an old photo using a contemporary map. For example, the screenshot above shows where the present-day airport complex is relative to the airport campus in 1946.

Last November, in a post titled Map updates, 2019 - 2020 we introduced a new interface design for toggling between historic map layers on the Mills Fields website.

We’ve taken that interface design and bundled it up as a standalone layers control element, written in JavaScript, for use with any Leaflet map. It’s called leaflet-layers-control and this is what it looks like in the go-www-geotag application, with our historic aerial map imagery.

There are a number of similar control elements for loading and toggling layers, including one that comes built-in with Leaflet itself, but we’ve chosen this one because we prefer the user interface, which has a simple data structure for defining arbitrary layers, it automatically adjusts the map based on a layer’s minimum and maximum zoom settings and exposes keyboard shortcuts for toggling between layers.

Here’s an abbreviated example in code of how to use it:

var lat = 37.6172;
var lon = -122.3827;
var zoom = 14;

var map = L.map("map");
map.setView([lat, lon], zoom);
	
var catalog = [
	{"label":"1937","year":1937,"min_zoom":12,"max_zoom":17,"source":"sfogis","url":"https://millsfield.sfomuseum.org/aerial/1937/{z}/{x}/{-y}.png"},
	{"label":"1949","year":1949,"min_zoom":11,"max_zoom":14,"source":"sfomuseum","identifier":"1997.52.084.014","url":"https://millsfield.sfomuseum.org/aerial/1949/{z}/{x}/{-y}.png"}
	// and so on, for a complete example see:
	// https://github.com/sfomuseum/go-sfomuseum-maps/blob/master/dist/sfomuseum.maps.catalog.js
];

var layers_control = new L.Control.Layers({
    catalog: catalog,
});

map.addControl(layers_control);
layers_control.addHash();

The final layers_control.addHash() statement is optional but if declared will update the current URL, in the browser’s location bar, to include both the map’s position and the current layer being displayed. When that URL is opened in another window the leaflet-layers-control code will inspect the URL and automatically load the correct layer.

Here are three different examples of the main Terminal Building (1953) on a map in: 1988, 1956 and 1997. As you can see we’re using this control in both the go-www-geotag application and on the Mills Field website for objects that have been geotagged. Which is the point!

In the first post in this series I wrote:

The cultural heritage sector needs as many of these small, focused, tools as it can produce. … We need to learn how to scope the purpose of and our expectations of any single tool so that we can be generous of, and learn from, the inevitable missteps and false starts that will occur along the way.

Our hope is that tools like the leaflet-layers-control help to demonstrate the value of designing things in a way that allows many small and discrete components to be carved out of a larger bespoke project, and re-used in a variety of settings.

In addition to publishing the JavaScript code for leaflet-layers-control we’ve also published a Go “middleware” package for the control. It’s called go-http-leaflet-layers and follows the same pattern as the other similar middleware packages we’ve talked about in parts two and three of this series.

Here’s an abbreviated code example:

import (
	"github.com/sfomuseum/go-http-leaflet-layers"
	"github.com/sfomuseum/go-www-geotag/www"	
)

func main() {

	editor_opts := &www.EditorHandlerOptions{}
	editor_handler, err := www.EditorHandler(editor_opts)

	layers_opts := layers.DefaultLeafletLayersOptions()
	editor_handler = layers.AppendResourcesHandler(editor_handler, layers_opts)
}

I started this discussion of the leaflet-layers-control element in the context of an SFO Museum specific geotagging application but both the JavaScript control and the Go middleware handler are already bundled with the default go-www-geotag application. We aren’t the only project that will need or want more than one map to use while geotagging images so it’s a good piece of functionality to make part of the core application.

The challenge I have right now is that I am unsure of the best way to define where the “catalog” files that list the different map layers to display should come from. Each project will have different maps so each project will have a different catalog file.

Should catalog files be read from a command line option when the application is started? Should there be another text field, like the ones for search terms or loading images, that the URL to a catalog file can be entered to? Is this functionality that is actually best saved for a custom version of the geotagging application like SFO Museum’s go-www-geotag-sfomuseum ?

I don’t know yet but if you have any thoughts or suggestions we’d love to hear from you. In the meantime, in the posts to follow, we’ll get back to discussing how to publish geotagging data remotely.