London Loop 16 – Borehamwood to Cockfosters

It’s been three months since the last leg of the Loop and suddenly the angle of the light and the colours it picks up are very different.

No photos

I went unintentionally off the route three times – more than in any other leg of the Loop. Once was because I was paying attention to the OS map (which was wrong) rather than the Loop directions (which were right), once because I read too much into the angle of a waymarking arrow, and once because the path ahead was broad and tempting and the waymarking which should have alerted me to the turn I should have taken missing or obscure.

And there was one I caught – an avenue rolling out ahead but a turn to be taken to the left. There was a substantial finger post – but it was carefully positioned behind a mature tree so as to be almost completely invisible. Instruction manuals are all too frequently written by people who know how the thing works. They would in many ways be better if written by – or at the very least, tested by – people who know nothing about the thing at all. In the same way, I suspect paths are too often way marked by people who know the way.

Dual carriageway detourThere was another kind of diversion earlier in the route. When the path meets a busy dual carriageway, there is no alternative to walking down one side and up the other, in order to cross the road safely. It adds the best part of a mile in the slipstream of fast moving traffic, a twenty minute reminder that the Loop is in part a grand illusion, rus in urbes.

I walked the last couple of miles through fading light. As the trees became monochrome and their shade steadily darker, only the fallen leaves held some residual colour, almost fluorescing against the surrounding darkness.

 

Route map for a customer journey

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. OS stuck update.pngBut 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. OS map install screenAnd 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.

OS error.pngThen 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.