Blog posts tagged geotagging
While this particular instantiation of the geotagging application is scoped to the physical boundaries of SFO the code itself is not specific to SFO Museum. It can be used, in combination with custom databases of map tiles and geographic data, with any image on your computer. This code will continue to be the common infrastructure that we build a SFO Museum application, specific to our needs, on top of.
The bad news is that, when you look closely, there really are that many moving pieces when it comes to something like geotagging photos. The good news is that nearly all of those moving pieces, from the underlying data to the tools to operate on those data, are within the reach of cultural heritage as low-cost and open-source alternatives to the commercial offerings. We may still need to stitch those pieces together to meet the needs of a specific institution but at least they are within reach now.
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?