A few weeks ago I thought I’d be clever (too clever it turns out) and try to integrate Dr. Drang’s map-photos.py Pythonista Script with Workflow so I could map photo locations directly from Photos.app. I was hoping to use Workflow to create an action extension that could grab a photo, put it to the clipboard and then run map-photos.py to display the location of the photo on a map without having to launch the script through Launch Center Pro or, slower still, opening up Pythonista, navigating to the script, and then tapping run. Unfortunately that project turned out to be a miserable failure because clipboard.get_image() in Pythonista doesn’t allow you to get the metadata of the image on the clipboard. Out of sheer laziness I left the useless workflow on my phone, taunting me every time I opened the app.
With the advent of general stability in Workflow 1.11, I decided to spend some time thinking about how I could better use the app. Tonight, for some reason, inspiration struck when I saw the Map Photos workflow looking me in the eyes. So I decided to take on the challenge.
The initial workflow idea was to create an action extension that could select multiple photos and display them all as separate pins on the map. While I think this is possible, I didn’t want to get derailed with that. I just wanted a reliable way to serially display multiple images on a map on iOS. The easiest way I could figure out how to do this was by using an X-Callback-URL. The problem is that there isn’t a reliable way to return to the source app when using an X-Callback-URL from an action extension on iOS. Also, Apple Maps doesn’t support the callback function of the X-Callback spec, obviously.
So I looked online and it turns out that Google Maps on iOS does support the X-Callback-URL spec, making the choice a no-brainer. So I built two different workflows:
- one that would be able to run as an action extension to map photos directly from
Photos.appas well as other apps, and - one that could take a series of images, display them in Google Maps, then return to Workflow to load up the location of the next image and send that one to Google Maps.
The what I like better about the Dr.’s method is that it actually grabs the Latitude and Longitude from the image file, whereas my workflows grab the address. I typically prefer Lat/Long because, especially in rural or newly developed areas, using the address can be highly inaccurate. This is another reason why I’m using Google Maps on iOS for this project. Three years into Apple Maps I still trust Google’s data more.
- probably because now I know that the steps of my workflows won’t just randomly be erased when running the workflow ↩
Sweetness of Freedom 