The issues he highlights can be broadly divided into two categories: problems with our stylesheets and rendering technology; and problems with our data, and in particular with our US data.

The issue which I intend to address here is the one he tackles first – that of label density which is something that stems largely from data quality and, more importantly, consistency issues. Specifically, although the post talks about cities, the real question is about what is tagged as a city and what is tagged as some lesser type of place.

By way of explanation I should probably start by explaining that in OpenStreetMap tagging there are four commonly used used values for the place tag which designate a populated place. In order, from largest to smallest, those are: city, town, village and hamlet. The question which then arises is, how do we decide which of those values to use for a given settlement?

Like so many tags the specific names used come, because of OpenStreetMap’s origins, from typical British usage. It is therefore generally not a good idea to interpret the names too literally in other jurisdictions — indeed some tag values like highway=trunk aren’t even interpreted literally in England!

To the British the question of which places should be cities is fairly clear — there are a few alternative definitions (places with royal charters vs places with cathedrals) but those only relate to a few edge cases and in general there is little debate and only a relatively small number of large and/or important towns will qualify.

At the other end of the spectrum a hamlet would normally only be used for very small places that amount to little more than a handful of houses.

In between lies the distinction between villages and towns which is much less well defined but in my opinion would generally lie around the few thousand mark in population terms — once you reach 2-3 thousand residents you are probably a town rather than a village.

Interestingly the OpenStreetMap wiki disagrees a little here and suggests hamlet for populations up to one thousand and village up to ten thousand. I would argue that both of those values are too high for normal British usage and certainly larger than I would use when tagging places.

All of which brings us back to the variations in density in the US map…

The first thing to understand about the US is that most populated places there appear have been initially imported from the USGS GNIS data set. I haven’t found any documentation as to how places were categorised but I suspect it was done based on population and most likely using the values in the OpenStreetMap wiki or something close to them.

Justin’s first example starts with the apparent high density of places in Florida so I took a look at a randomly selected place in his example which appeared to be fairly small — the town(?) of Frostproof. The OpenStreetMap history for Frostproof reveals that it was originally imported from GNIS as a village (probably because of it’s population of 2922) but has recently been retagged as a city.

My suspicion is that this is the result of an overly literal interpretation of the place=city tag – as I understand things many relatively small places in the US officially style themselves as cities — certainly Wikipedia describes Frostproof in this way. Nobody in Britain, or indeed probably in Europe as a whole, would consider somewhere that small to be a city however and tagging it as such certainly goes against normal OpenStreetMap tagging practice.

In most of the rest of the US no such retagging of small towns as cities appears to have taken place, making place names there appear much less dense at low zoom levels. The sort of places which Justin’s article suggests should be appearing in those areas mostly appear to be in the 25-100 thousand population range and hence have been tagged as towns during the GNIS import. The solution here, if more place names are considered cartographically desirable, would either be to adjust the threshold at which places are tagged as cities instead of town, or to alter the stylesheets to render towns at lower zoom levels.

The relatively high density around Los Angeles which the article mentions appears to be the result of a fairly large number of places with populations just over the 100 thousand mark. Despite their large populations, and the fact they are likely independent cities legally, I suspect that many of them would be tagged as suburbs in Britain rather than as cities or towns and hence would be given lower priority when rendering.

The real lesson to be drawn from all this however is that the US OpenStreetMap community probably needs to reach a consensus on how to map populated places to tag values so that a better level of consistency can be achieved with less variation from area to area across the map.

ITO World have now made use of that data to do a comparison with OpenStreetMap and produce a set of tiles which can be overlaid on OpenStreetMap to highlight roads in OS Locator which do not appear to be in OpenStreetMap — that doesn’t always mean the road is missing, or even missing a name — sometimes it just means we don’t agree on what the name is!

A case in point is a road near me called Oxenden Drive. At least that is what OpenStreetMap thinks it is called — the OS Locator data calls it Oxendon Drive instead as shown in this show of OpenStreetMap with the ITO World overlay:

Oxenden or Oxdendon?

So today I paid a visit to recheck the name on the signs and sure enough, the signs agree with OpenStreetMap and say Oxenden Drive.

The Hertfordshire County Council Gazetteer seems to agree with Ordnance Survey (Oxendon) while Royal Mail’s address database comes down on the side of Oxenden.

At the end of all that I’ve decided to leave it as it is, as Oxenden Drive, but who knows what the real answer is…

Well I’m delighted to say that today a representative of the publishers posted a comment on that piece apologising and explaining what they’re doing to correct things and to make sure it doesn’t happen in the future.

So I think that’s a belated “Well Done” to New Holland Publishers.

The Isle of Dogs from The London Cycling Guide

By way of comparison, here’s how the same area looks in OpenStreetMap at the moment:

The Isle of Dogs from OpenStreetMap

Obviously the maps in the book have had extra information added, and some things like stations changed a little, but the base map is clearly both OpenStreetMap data and OpenStreetMap cartography.

Naturally enough the first thing I did was to turn to the acknowledgements to see what nice things they would have to say about the project, and indeed we do get a mention, though more in passing than anything. What it says is:

All other maps by Steve Dew using base maps by Openstreetmap

More alarming however was what I found at the front of the book, among all the other copyright statements, where it has the following line:

Copyright © 2010 in maps New Holland Publishers (UK) Ltd

Whilst it is probably true that there is some copyright (in the additional work done on top of the base map) which vests with them, there is also clearly a substantial amount of work whose copyright lies with members of the OpenStreetMap project.

As far as I can tell nowhere does it indicate that the maps carry a CC-BY-SA license, which they must do, by virtue of being derived from OpenStreetMap maps which carry that license.

Don’t get me wrong, I love that people are using our work (and my own work even – some of the area shown above was surveyed by me) in this way – that’s the whole point after all. I just wish they would spend five minutes to properly credit us and to point people at the license, both of which the license actually requires them to do.

For the record, the first map in this post is © OpenStreetMap and contributors and New Holland Publishers (UK) Ltd and the second is © OpenStreetMap and contributors. Both are licensed under CC-BY-SA.

]]> http://compton.nu/2010/05/how-not-to-credit-openstreetmap/feed/ 6 http://compton.nu/2010/03/response-to-os-consultation/ http://compton.nu/2010/03/response-to-os-consultation/#comments Wed, 03 Mar 2010 17:42:48 +0000 Tom http://compton.nu/?p=259 I finally got around to writing my response to the government consultation on releasing Ordnance Survey data – you can read my formal response but the summary is basically that yes I would like them to release some data but there are serious issues around some of the details such as the proposed license.

That said, I wasn’t (as I made clear, maybe a little too forcefully, in a comment on his post) particularly impressed by the unilateral way he went about it, or the approach he used to the redesign, or the result.

That all sounds (and is) rather negative so I thought that I would, in the cold (and more sober) light of day try and write something more positive explaining what I see as the current problems, how I think we should go about fixing them, and what I think a solution might look like.

Current Problems

As the person that usually winds up making decisions about whether to add things to the home page, and where to put them, there is often pressure on me to add particular things to the home page or to give them more prominence, all of which is very difficult when 90% or so of the page is taken up with the map. Common complaints I hear are:

• The search box is too small and/or not prominent enough.
• Item X (often the search box) is too far down the sidebar and falls off the bottom of my screen – especially common when we have extra items in the side bar to promote important events, votes, funding drives, etc.
• Can we add Y (for almost any value of Y) to the home page.

Another obvious (to my mind anyway) problem with the home page is that for a newcomer to the project it gives little information about what the project is and why it is more than just another “internet maps site” like Google, Bing or Yahoo. There are two short paragraphs of quite small text on the left hand side but they are not exactly prominent. One issue here is that there are essentially two entirely separate classes of user that the home page needs to address – newcomers who need to be introduced to the project, and existing users who quite likely just want to see the map.

From a pure style and design point of view there are many, many places where the site is horribly inconsistent and this is something that should certainly be tided up as part of any redesign. The sort of things I have in mind are:

• Inconsistent layout of forms – do labels have trailing colons? does the submit button align to left or right?
• Inconsistent capitalisation – basically do we use capital letters or not.

The use of tabs is also a problematic area of the site and the current site almost certainly has too many – the basic problem is that tabs (at least as currently implemented) don’t scale well as the width of the window reduces. This problem is obviously worst on smaller screens, and also in more verbose languages where the tab names can be significantly longer.

Approaching a Redesign

What I have been suggesting for some time is that we have a hack weekend, with the relevant technical people present as at previous hack weekends, but also with some people experienced in design and UI issues. The problem of course is finding such people and persuading them to attend.

More recently I have started to think that, in order to get maximum benefit from any access to design experts, a first stage should probably be to sit down as a group (at a hack weekend or similar) and brainstorm exactly what the problems are with the current site. This would then lead into the creation of some sort of design brief describing what we wish to achieve in any redesign.

Such a brief would (a) give us something we could give to designers to consider and (b) provide a means by which to evaluate the results of any design exercise. It also opens up the possibility of not needing the designers in the same room as the domain experts and implementers which may make getting access to design expertise easier.

Possible Solutions

I realise that, by offering some possible solutions, I am now jumping the gun a little as my own view is that we should be enumerating the problems first, but hopefully a few broad brush ideas may be helpful without expending too much energy ahead of having established the goals.

One possibility for the front page is something along the lines of the “three panel” design that was once proposed, where the map takes up much less space on the page and there is much more space for introducing people to the project. Such a design should probably be combined with a quick way to jump to a full page map view, and a means for logged in users to have that as their default view.

Another option might be some sort of translucent overlay, or a Stack Overflow style “tip bar” that is displayed to new visitors although such a design has some problems of it’s own – being displayed too often to users with cookies disabled, and possibly not often enough to new users who may need to see it more than once.

As far as minor style issues go the solution is really fairly simple – we just need to document what our style is and then stick to it.

Tabs are a harder problem – we really need less I think which means finding some alternative UI mechanism to expose some of the things which are currently on tabs to the user. The export tab is certainly a prime candidate for change here as it really belongs with other things like the key, search, etc which open a sidebar while keeping the map displayed.

Other Issues

There are couple of major features that are often asked for, and which we should probably have, but which are not strictly linked to the question of redesigning the site. The things I’m thinking of here are:

• A means to allow people to report problems with the map data – something like OpenStreetBugs but properly integrated in the main site.
• A routing engine – not because we want to be a full service end user map site but because it helps find (and fix) topology and turn restriction errors in the data.

These are things which are independent of a redesign in as much as that they could perfectly well be added to the current site if we wanted, or added to the site after the basic redesign – they don’t have to (but could be) added at the same time as any redesign.

My main wish in respect of either of the above things is that they be properly integrated in to the main site and running entirely on servers maintained and operated by the project. Obviously they also need to be able to handle the load generated by being on the main site.

Summary

I hope that this post has provided a rather calmer and more measured description of where I think we are, how we should go about moving forward, and what the future might look like and that we can now move forward in a calmer and more measured way than some of the rhetoric of the last twelve hours might suggest.

The basic editing of roads and such doesn’t seem to be much improved from the (fairly dire) interface we saw in the previous alpha builds – trying to move nodes in a way is still way harder than it should be, working out how to start a new way is even harder, and it still seems to be impossible to end a way unless you remember that you want to do so before you add the last node. As to extending a way well I’d forget it if I were you as I’ve never found a way to do it, or to join a new way onto an existing one (which would be a workaround for not being able to extend a way).

Presumably there is some help somewhere, but there is no effort to promote it as far as I can see – no “you might want to read this before you start” type prompts. There is a “help” link but it just goes to a CloudMade wiki page showing how to connect Mapzen to your OpenStreetMap account.

One word of caution by the way – there doesn’t seem to be any indication whether or not you have any outstanding edits that need to be saved, and the “Close and Exit” button does exactly that, without any sort of warning if you have unsaved edits which will be lost.

Perhaps the most worrying thing however is the so called “Mapzen Dashboard” which provides the entry point to the editor. That isn’t the problem however – the problem is that it provides it’s own, CloudMade hosted, social environment with “friending”, “messaging” and “home locations”. Anybody familiar with OpenStreetMap will know that the core site already provides all those things (though not as slickly) so the obvious question is what exactly CloudMade are doing duplicating this? Is this an attempt to create some sort of parallel community to the main OpenStreetMap community?

Overall I think we have to class the editor as a fail for now, and the dashboard as something that needs more explanation.

The comments on their blog posts rather beautifully demonstrate just how quickly you can trash a carefully built brand by failing to anticipate and prepare for the load generated by your own marketing antics. It really is a brilliant exhibition of just how EPIC a FAIL can be.

This was all of interest to me because they are apparently making use of OpenStreetMap data in some way – exactly how is not entirely clear because nobody can get in to find out!