If you use JOSM, please download an up-to-date copy from josm.openstreetmap.de if you are unable to edit.

Java uses its own SSL stack, and it is rather special. Java 6 and 7 won’t talk to servers patched with Logjam. This means that the JOSM welcome screen won’t load, and you won’t be able to download or upload any data from the OSM API, because both servers have been diligently patched.

Last night, I thought this was due to my Internet connection being dodgy. Reading about Logjam this morning made it click.

And, yes, this will affect a whole lot of people outside of OSM-land…

I’ve been mapping for a while now. I have some issues with the way OSM currently works.

1. The current tagging/import approval process is silly. To get a new tag approved formally, you are supposed to post about it on tagging-l. Then you are supposed to write a wiki page, then have comments on the wiki page, then have an RfC on the wiki talk page, then announce the RfC on the mailing list. If someone says “yeah, I’m not wild about this idea”, that’s pretty much a blocker for it happening at all. The alternative to this process is to simply start putting tags on things when you edit them and create an informal convention. Because the former process is so ludicrously painful and slow, it is much easier to tell people who you meet who say “I’d really like to start putting X on OSM” to just go ahead and do it quietly without telling anyone, and then it probably won’t be a problem.

2. The wiki doesn’t match reality. The RfC process is so ludicrously over-complicated partly because nobody is sure whether the wiki exists to document existing behaviour or to specify what ought to be done. That is, nobody is sure if the wiki is descriptive or normative. It has thus ended up being both and neither.

3. There doesn’t seem to be a process for ever tidying the wiki, and no feeling that we should ever bring discussions to an actual consensus. Over on Wikipedia, for all its faults, admins do at some point close discussions and say “here’s the rough consensus: X”. On OSM, the discussions just rumble on forever.

4. The culmination of this slow and silly process for approving proposed tags or imports is that now when friends come to me and say “I’ve got this really awesome idea for using OSM and we could contribute data back”, I now say “yeah, good luck with that: the community process is so slow and bureaucratic, it often isn’t worth bothering with”. That’s toxic. It’s absolutely ghastly that smart, informed programmer types come to me and say “we’ve potentially got some amazing data we could contribute to OSM” and my answer is “that sounds awesome but the process is so broken that you shouldn’t bother doing it officially, just do it quietly and unofficially”.

There’s some simple things we could do to fix this.

1. Close most mailing lists. Mailing lists suck. Over at microformats.org we eliminated all our mailing lists and just use a wiki instead. See wiki is better than email.

2. Get rid of most of the RfC process. It doesn’t work.

3. Switch to a default of “let’s allow things to happen, then fix them when they break” rather than the current “let’s have long, pointless mailing list discussions and then say no”.

4. Develop a process that is based around evidence collection. When I proposed the dress code feature, I provided comprehensive examples of different types of dress code that people were actually publishing on the web. The point is that when deciding on a new tag or feature proposal, we should be guided by the evidence of what people are already trying to express in other settings. The alternative process to this is called “making shit up out of whole cloth”. It has a proud and noble tradition in standards-making. Alas, that tradition is also accompanied by a history of complete failure.

If we want enthusiastic contributors to work on making OSM fill all sorts of interesting and unpredictable new use cases, we should welcome those people in rather than keep around processes that are slow, bureaucratic and alienating.

I’ve been contributing to OpenStreetMap for a while now, but I actually put OSM data to the test today.

A family member bought a new vehicle recently which has a built-in manufacturer-supplied GPS with proprietary mapping data on it. We decided to have a drive today to test it out. I brought along my Garmin eTrex 20 loaded up with OpenStreetMap-derived TalkyToaster maps. TalkyToaster’s maps are routable and have a large number of points of interest.

We did a 35 mile drive down to Dungeness in Kent. While there, I did some site surveying in the freezing cold and have made a few updates to OSM.

The routing mostly worked. And the data was good. On the outward journey, I checked a lot of the side streets we passed by, and all those I checked had the correct name and There was only one problem I found with the data: there was a tiny little cul-de-sac I spotted that wasn’t on the map. I added it as a waypoint on my Garmin and will add it to the map when I next transfer data off.

The routing had only one problem and that was on the return journey, while driving along Lower High Street, Wadhurst. Rather than continue on to the High Street, the Garmin device instead said that one should turn into Church Street. Church Street is a tiny single-width street that is only used for access and is tagged highway=residential. You wouldn’t drive up it, especially in a larger vehicle like a van. It actually has a warning sign forbidding HGVs from entering. But the Garmin was quite insistent that one should drive up there. The manufacturer-installed GPS accurately stated to carry on along the High Street.

I shouldn’t be surprised at how good OpenStreetMap data is (I’ve added plenty of it), but this slight routing mishap aside, certainly here in the south east of England, it is now pretty damn close to good enough that it can be used for in-car navigation. Having seen how much data upgrades are for some car GPS units (as much as £150 in some cases), the future really ought to belong to OpenStreetMap.

We’ve got open data, we’ve now got open source operating systems (Linux, Android), cheapish hardware, Kickstarter for funding: someone could build a completely open source satellite navigation system…