Potlatch – the OpenStreetMap editor

I’ve not been very good at keeping this blog up-to-date. The last posting was about Potlatch 0.11. In the five months since then, we’ve moved onto 1.2c, with some pretty massive improvements: offline editing, POI icons, online help, one-way arrows, a fix for the infamous Linux Flash Player Unicode bug, photo-mapping, the ‘inspector’ panel, a roundabout button and a whole load else. (You can see the full list over at the changelog.) And then there’s Potlatch 2, but that’s a whole other story.

But sometimes things change under the surface, and today was one of those days.

Potlatch doesn’t talk XML like other OpenStreetMap applications; it uses an efficient Flash protocol called AMF (Action Message Format) instead. AMF has some very cool features, and one of these is that it can stream data.

So we’re now using this. When Potlatch previously asked for data from the OSM server, the server would assemble it into one big chunk before sending that back. Now, it sends each way back as it fetches it from the database. The same goes for uploads; the server now responds to each uploaded way in turn, rather than waiting until the last one is done.

Sadly Flash Player still waits until the download is complete before displaying the ways. (It would be much cooler if ways were displayed one-by-one.) But there are still a couple of advantages.

Firstly, uploads in particular should be less likely to hang if there’s a regular flow of information back. Secondly, the server needs to keep less information in memory at any one time – quite a lot less if you’ve asked for a densely-mapped city at zoom level 14. This is a Good Thing for everyone as it makes the server faster.

I’ll occasionally post a few tales from the development of Potlatch for those of a more technical inclination.

Potlatch makes very heavy use of Flash’s built-in events. Some of these are fairly simple mouse events. Each MovieClip (a “sprite”), for example, has events including onPress, onRelease, onRollOver and onRollOut. Potlatch uses these to tell when you’ve clicked on a way, or dragged the map, or clicked a button.

Fine so far.

Flash also has really useful events for textfields. Potlatch uses onSetFocus, onKillFocus and onChanged. So, when you’re typing a tag name or value, every keypress triggers an onChanged event; when you click in the value, that triggers an onSetFocus – and possibly an onKillFocus for the textfield you were in before.

The tricky bit is that sometimes these events don’t fire in quite the order you expect.

Take the blue autocomplete menus. If you select an item in one of these, Flash fires an onPress event for the menu, just as you’d expect. But it also fires onKillFocus for the textfield that you’re editing – and it does that before the onPress event.

The result is that Potlatch sees that the textfield has lost focus; looks in the textfield; probably sees it’s empty; and thinks “oh, the user is leaving the textfield with the value empty, that means they want to delete the tag”… and deletes the tag. So when onPress fires immediately afterwards, there’s no tag any more to put its autocomplete value in.

This is the sort of thing that is really, really horrid to debug, trying to work out which order things are firing in. I eventually fixed it by adding a new onMouseDown event for the whole of Potlatch, which simply notes a mouse-click – and this, happily, fires before both onKillFocus and onPress. So the onKillFocus event now checks for this; if it figures “yes, the user has just clicked the mouse”, and the mouse is currently over the autocomplete menu, it just returns without doing anything.

(This fix is one of the new things in 0.8!)

Another case. When you press “+”, Potlatch adds a new blank tag, and helpfully selects the ‘key’ field for you. Except if Flash had its way, it would then promptly populate the key field with the string “+”. I figured “+highway=trunk” is probably not a useful OSM tag, so there’s now a couple of lines of code to say “if it looks like the user has changed the key to +, they probably don’t mean it”.

So apologies if your super-duper private tagging scheme uses + as a key, because Potlatch won’t let you enter it.

Incidentally, there’s some relevance here to the is-the-iPhone-getting-Flash-or-not discussion. Performance? Not a problem – AVM2 is reputedly pretty fast on ARM, and hey, it works on the much less powerful Chumby. Choking the iPhone? I don’t think so – Safari on Mac already restricts Flash CPU time if it’s not frontmost anyway. Politics? Yes, almost certainly. But the big development problem as I see it is that events like onMouseUp don’t easily translate to iPhone touch events, and a lot of Flash apps are built entirely around these events. I’ll be really interested to see how Adobe gets around this.