Blog posts tagged collection
We want to see what these technologies make possible, though, and a very real and immediate opportunity is the ability to index search terms that the curators and registrars haven’t already included in the titles or descriptions for objects in our collection. For example, this travel bag from Canadian Pacific Airlines, covered in the names of cities the airline traveled to, is not included in the search results for the terms “montreal” or “saskatoon” using the default search functionality but it’s the first result when we also search for the text in images.
In the same way that we can wrap a traditional web application in a Go program, can we wrap that Go program in a native macOS application? Each platform has its own unique affordances and tolerances. A larger goal for the museum is recognizing the possibilities that each platform affords so that we might be able to treat them as a kind of “kit of parts” to be reconfigured as needed for future projects.
This post is about the go-www-geotag-sfomuseum application. It adds support for authenticating users and publishing data to any service that supports the OAuth2 standard. For the purposes of this post we’re using GitHub to demonstrate our work because we already publish all our open data on GitHub so it is useful for our geotagging application to be able to write directory to their API. In the future we might update our geotagging application to talk to SFO Museum’s own OAuth2 and API endpoints.
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.
In order to support SFO Museum’s use case we would need to bundle all of the code required to implement the steps described above with the go-www-geotag application. That’s a lot of functionality that which not germane to another user of the application. It’s also, potentially, a lot of code that SFO Museum may not want or be able to share publicly. It’s a scenario that would have to be repeated for every custom writer adding unnecessary complexity and size to the final geotagging application.
So far, we’ve got a map and a camera, a global search endpoint, a simple way to query for and display images and enough information to display already geotagged images correctly. Importantly none of these things are specific to our museum or any other institution. In fact there’s nothing about go-www-geotag that is specific to the cultural heritage sector at all. You could use this tool to geotag any set of images. But what about saving the geotagging information that the Leaflet.GeotagPhoto extension produces?
If the go-www-geotag application is designed to be agnotic to the details of any one user’s data sources how does it know where to find and load the images it’s meant to geotag? Isn’t this exactly the problem I described in the first post in this series, a scenario where the go-www-geotag application is required to know about an infinite number of image sources? Rather than trying to support a potentially infinite list of image sources we’ve decided to require the use of the oEmbed standard as the means by which images are identified and loaded in to the application.
But what if you want to center the map on a different place and don’t already know its latitude and longitude coordinates? What if you need to jump around to a bunch of different places all over the world?
I call this the “building with two-by-fours” stage of development to highlight the importance of not just building things quickly but equally being able to disassemble and rearrange them just as easily. Sometimes this happens at the expense of elegance and finish but that doesn’t diminish their importance or a commitment to address those things.
In the end we may deploy this application for staff as a hosted website on the internet but we would like to have the ability and the flexibility for staff to also run the application locally, from their desktop. The majority of museum staff are not developers and won’t know how or be able, or want, to install the external dependencies that might be necessary for an application written in another programming language to run.
This is the first of multi-part blog post (11 in all!) about geotagging photos in the SFO Museum collection. It’s also a blog post about how we’re doing that work and why we’re taking a longer road than we might otherwise to get there. Over the course of the next couple weeks we’ll post one short blog post a day focused on a specific step, or area of concern, in that process. This first blog post will set the stage and outline some of our motivations for seeing geotagging photos in our collection as a chance to address larger issues in the cultural heritage sector.
A healthy slice of the permanent collection of the SFO Aviation Museum and Library is now available for browsing on the Mills Field website. This includes a little more than 23,000 object records of which 18,000 have images. This is still only a small part of the museum’s total holdings and we hope to get all, or most, of the remaining objects online shortly. Like all the images on the Mills Field website, every image from the permanent collection is “zoomable”.