The leg of the London loop I walked in July prompted a paragraph on the glories of the Ordnance Survey map app. The leg of the Loop I walked at the weekend elevates the app to a post of its own, though not in a good way.
I knew I had the Ordnance Survey sheets I needed loaded on my Nexus 7 and that they would be available whatever the state of my data connection along my route. But the OS app took it into its head to update itself. Or rather to fail to update itself. It got to 33% of something and froze with the excuse that it could not access the internet. There was in fact a perfectly good – if not outstandingly fast – internet connection so the excuse was a pretty thin one. After a few frantic minutes of prodding and restarting, the penny dropped: it was only prepared to update over wifi (though that’s not what the error message said). I got round this absurd problem with an absurd bodge: setting up my phone as a wifi hotspot made the app happy that it was getting data the way it wanted, even though the underlying source was exactly the same as the mobile data connection it had turned its nose up at.
It should be pretty obvious that updates – particularly updates requiring significant amounts of data – should happen when the user chooses. It should be pretty obvious that the fallback to a failed update should be that the earlier version continues to work, not that the whole app locks up completely. And if progress is being stopped by a preference setting, it should be pretty obvious that giving the choice of changing the preference is better than defaulting to failure.
Eventually the core app did update itself – at which point a new problem appeared. I have 36 OS sheets linked to the app, all labelled according to OS grid referencing, with snappy names such as SH62 and TQ37. And every one of them now had to be reinstalled. But of course at that moment, I didn’t want all of them, I just wanted the two needed for the walk I was about to start. There is, as far as I can tell, no way of identifying from the list of available sheets what each of the map areas covers, and while I am proud of my cub scout badge in map reading, I can’t guess the ones I need. There is a decidedly non-intuitive way of working round this problem too, by going through the process of buying the sheets I already own, since doing it that way does show map coverage (though not the map reference numbers) and does install the updated versions without charging for them again. Had I been at home with a good data connection, I would have taken a much simpler approach, and just clicked on update all. Except that there is no such button: to get the app back to the state it was in before OS started trying to be helpful will require 36 manual updates.
All in all, it took over twenty minutes to get a usable map. The one saving grace is that I was on a train – if I hadn’t discovered the problem until I had started walking, I would have been much more irritated.
Then about five miles later, I discovered a very different kind of problem: the map was plain wrong. The screenshot show the west to east footpath passing two footbridges, crossing from the south to the north bank of the Dollis Brook at the more easterly one. It actually crosses at the westerly bridge. Other than the pointless circumnavigation of a field, no great harm was done – but it’s curious that the path on the south bank not only doesn’t exist but can’t have existed for a very long time as there is not even a trace of a gap in the hedge for it to get through to the second footbridge. But at least by that point, I had a map.
Walking round the London loop, an OS map is a luxury rather than an essential. But there are plenty of times and places where a good map is more critical and where a data connection is somewhere between shaky and non-existent. If you can’t trust the OS not randomly to want substantial data downloads and to stop working if it doesn’t get them, you can’t trust it at all. This really needs fixing.