Geotagging at SFO Museum, Part 4 – Search

This is a blog post by aaron cope that was published on April 28, 2020 . It was tagged sfo, collection, geotagging, placeholder and search.

photograph: San Francisco Bay Area aerial, delta. Photograph. Gift of Charles Page, SFO Museum Collection. 2010.174.344.

This is the fourth of an 11-part blog post about geotagging photos in the SFO Museum collection. At the end of the last post we demonstrated the foundations for our geotagging application, called go-www-geotag.

The go-www-geotag application has a number of flags to configure its behaviour including changing the initial map view which, unsurprisingly, is the San Francisco International Airport.

If you wanted, for example, to open the application across the San Francisco Bay at the Oakland International Airport then you could specify its geographic coordinates at start-up, like this:

$> ./bin/server \
	-nextzen-apikey {NEXTZEN_API_KEY} \
	-initial-latitude 37.7127 \
	-initial-longitude -122.2118 \
	-initial-zoom 15

2020/04/24 16:56:32 Listening on http://localhost:8080

And when you open the application in your web browser you’d see this:

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? Do you remember how I mentioned the Using the Placeholder Geocoder at SFO Museum in the last blog post? A “geocoder” is exactly what we need here.

If you’re not already familiar with the term “geocoder” Wikipedia describes a geocoding as “…the process of taking input text, such as an address or the name of a place, and returning a latitude/longitude location on the Earth’s surface for that place”. That’s what a geocoder does.

photograph: San Francisco Bay Area aerial, Oakland port, San Francisco. Photograph. Gift of Charles Page, SFO Museum Collection. 2010.174.449. Also, look at that: San Francisco Bay without any bridges!

The Using the Placeholder Geocoder at SFO Museum blog post describes how SFO Museum set up its own instance of the Placeholder geocoder including a custom web-application, bundled with all its depedencies and assets, for using it.

Placeholder supports global, multi-lingual “coarse” geocoding which means it can parse everything from continents to neighbourhoods, using openly licensed data, but doesn’t know how to handle street addresses. It also does not support querying for airport yet which can be frustrating for us but we plan to fix that shortly. Overall we think the benefits of the Placeholder application are worth its few shortcomings.

Rather than bundling Placeholder in to our geotagging application we’ve added support for specifying an endpoint that our application can talk to programatically using the Placeholder API. The details of running Placeholder are still sufficiently complex that it continues to makes sense to deploy it as a separate application. There are some promising developments that might simplify things but it’s too soon to know for sure yet.

To enable Placeholder support you’d start the application like this:

./bin/server \
	-nextzen-apikey {NEXTZEN_API_KEY} \
	-enable-placeholder \
	-placeholder-endpoint {PLACEHOLDER_API_ENDPOINT} 

2020/04/15 08:58:22 Listening on http://localhost:8080

When you open the application in your web browser you’ll see a handy search box above the map that you can query. Clicking on a query result will set the map’s view port to that place.

Support for the Placeholder API is very basic and there are still a lot of details to attend to. Most pressing is improving the way place names are displayed in the query results. As you can see from the screenshots, above and below, lots of places have the same name and the current interface for deciding which place is correct requires a leap of faith.

What we really want is something similar to the way the Pelias leaflet-plugin formats its results:

Pelias is also a geocoder. It is Placeholder’s older sibling and knows more tricks, like resolving queries for addresses. Both are open source products under active development by the Geocode Earth group.

Ideally what we’d like is a similar Leaflet plugin for the Placeholder API so that the query box, and its results, could be contained by the map itself. In the last post I wrote:

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. We’re just not there yet.

That’s where we are with support for search in the go-www-geotag application. We’ve proven that the application can be configured to conditionally enable and make use of the Placeholder API. We have a basic interaction model and we understand how to account for its shortcomings while we continue to develop the rest of the application.

After the “building with two-by-fours” stage of development is the “polishing the door knobs” stage where we smooth out all the rough edges and make things pleasant to use. It’s just too soon for that right now. If you’d like to help out before we cycle back to this then your contributions would be welcome. A general purpose Leaflet plugin for the Placeholder API would be something that lots of different applications could put to good use.

By now, you might be wondering: If go-www-geotag is a tool to geotag photos then… where are the photos? That’s the subject of our next blog post.