There have been a couple of threads on OpenStreetMap’s mailing list this month to do with change. The first, entitled “Request for feedback: new building colours in openstreetmap-carto”, is all to do with a change to the way the default map style looks on openstreetmap.org. The second, “MEP – pipelines”, refers to a mechanical edit of the OpenStreetMap data. Both have been met with some level of resistance – but is this proportionate?
Change: For and Against
Failure to adapt and change can result in obsolescence and opens the door for new innovative competitors. The same is true for OpenStreetMap. We rely on an army of mappers to continue to contribute data and many of these mappers are motivated by the idea that the map data is being used and not just sitting idle. As our users’ needs change, so do our contributors’ – we are faced by a constant requirement to adapt. Fulfilling these requests for change in a timely manner is great for the long term success of OpenStreetMap.
Take tags for example: we don’t have a rigid set of tagging rules and as such contributors can come up with their own tags for new, never mapped before features. Over time preferred tags become more populous and gradually more contributors adapt to use the common tag – old tags may even get updated. If our contributors didn’t change then our data would be a miss-match of ‘stuff’ and would be difficult to add to and problematic for our end users.
But change is not always a good thing. Those same users who require us to adapt, are also likely to want us to provide a stable product. Our users have products and services that rely on our data and when we change something they may also need to update something on their side. As such unrequested change, or change with insufficient notice, may cause as much problems as a failure to adapt when desired.
“As OpenStreetMap matures the amount of prior notice of changes we will be expected to give will increase and we will be expected to announce planned changes to some of the smaller things”
Change in OpenStreetMap is often done in small evolutionary steps, however we’ve seen big changes too, such as the licence change and the introduction of new editing software. As OpenStreetMap matures the amount of prior notice of changes we will be expected to give will increase and we will be expected to announce planned changes to some of the smaller things, not just the big ones.
So lets look at the two changes currently being discussed on the mailing list.
Case 1: “Building colours in openstreetmap-carto”
This first change is to do with how the default map style on openstreetmap.org looks. It forms part of a larger piece of work to bring some standardisation to our default style. The changes come after a period of stagnation a few years ago during which it was often commented that our map style was a hotchpotch of colours, line styles and widths. The current changes bring standardisation and set the foundations for us to add new POIs (another often requested change). The general lightening of the style also makes it more suitable as a background layer to display overlaid data (again, often requested).
But who are the affected users? Well, OpenStreetMap is a data project – we create data and we distribute data – its right there on the wiki home page. The default map style, on the other hand, is provided as an additional extra: a bonus. We specifically limit the use of our default map through our ‘Tile Usage Policy’.
If you are an end user and are not happy with the change then you have an alternative. Simply grab our underlying data and render your own map using any style you wish. You could even use a previous openstreetmap.org default style!
Case 2: MEP – pipelines
This second change is a data change. It follows my example above where some work has been done to try to improve the tagging of a certain feature – in this case pipelines. The aim here is to create new use cases for our data. Although it hard to be certain, I would imagine that very few users are currently using our pipeline data. As such a notification of change, followed by a reasonable period of time for people to adapt is probably appropriate.
But was change even needed? Possibly yes – the aim is to improve both the quality and quantity of our data and to avoid potential conflicts with other tags. On the other hand, these conflicts are minor and most data users could work around them. So change may not be needed.
In this case I tend to look at the bigger picture. We have a group of contributors who are trying to help, and we probably don’t have many users of the pipeline data right now. If we block the change we won’t cause problems for our users (until they come to us and tell us that we’re not adapting to their needs!) but we risk putting a group of dedicated contributors off OpenStreetMap for good. In this case I believe the best solution is to support the change.
Your thoughts?
I’d love to hear your thoughts on this – where is OpenStreetMap in its maturity and what level of change is appropriate? Is there anything you would like to see changed? And is there anything that must stay the same?
Mike N
I agree that change in the default OSM Mapnik layer is a good thing. Anyone who needs a certain look is free to use Mapbox or create their own.
OSM data tag changes are trickier since there are a number of data consumers. I agree that data tags are needed in certain cases to greatly improve the value of what is being mapped. Perhaps there could be a single channel (A wiki page, mailing list) where tag convention changes would be announced, along with a schedule of migration. Data consumers would be expected to subscribe in order to be notified of tag changes before finding out that their OSM data processing has failed.
JBJ
Your assertion about the color change overlooks the fact that OSM has a face we present to people as we try to get them to switch over, whether as data providers (mappers) or data users who might want to create their own tiles.
This face is http://www.openstreetmap.org and it contains a map of the world, a default front to the data in the database. Presenting the prospective users with nearly invisible buildings is going to be a problem in retaining their enthusiasm.
It is an old adage – one that programmers have often failed to take notice of. Frontend matters, usability matters. The rise of Apple with sometimes inferior and always more expensive products was fueled through their adherence to Making It Look Good.
Ignore that at your own risk.
FJ
Changing the building color is the single greatest improvement in the main map style since I started.
It’s been discussed before, but admin boundaries should probably be in a separate database. They are broken far too often and conflict with physical objects (the most important part of OSM).
Badita Florin
As i suggested on the mailing list also , at least for the visual changes we can facilitate the users to get used with the proposed changes
Mailing list mail :
My idea, for the future, if somebody can implement that, is to make a matrix of the types of landscapes and the types of buildings, and run it all against all.
And have a simulated OSM map with all of the data
On the Y axis it can be the type of landuse, and on the X axis it can be the type of building, of the most common combination ( building=school , amenity=school )
Whatever it will change the color of the the map.
This is a JOSM representation, but on the real Mapnik the Results will allow bot better adjustments before putting the change in front of tens of million of people
Photo Link if the mailing list does not support inline images http://s1.postimg.org/62c40ngen/josm_ilustration.png
Q
Destructive edits (either through vandalism or mistakes) is a growing problem that needs better tools to solve. In particular one instance was not able to be fully resolved, even after it was noticed and discussed on a mailing list.
The area that is clearly still vandalized:
http://osm.org/go/Zc50TTtNZ-
The user responsible:
https://www.openstreetmap.org/user/jjjj44445555
The mailing list thread:
https://lists.openstreetmap.org/pipermail/talk-us/2014-November/013799.html
Events like these show there is still much room for improvement.
SomeoneElse
I sent that to the talk-us list rather than just remotely fixing it because I thought that there (just outside NYC itself) there would be people able to confirm on the ground what the story was. Unfortunately that didn’t happen, and the area has now been tidied up (by a London-based mapper – thanks Harry!).
When “odd” data appears in the UK or Ireland (and lots of other places) someone spots it pretty soon, gets in touch with a local mapper and it gets tidied fairly quickly, like with https://twitter.com/czajkowski/status/519846771267497984 . This doesn’t seem to be happening with the US, and I don’t think that it’s a “tools” problem so much as a “people” one.
Q
@someoneelse
Yes, I think that has to do with the lower population density of the US. More eyes would be helpful, but it would also be helpful to be able to fully redact changes once an editor is known to be malicious. Even a manual clean-up is not entirely effective as there are still things that are missed after several eyes and rounds of editing. See https://www.openstreetmap.org/node/707487406
Attempts at using reversion tools failed, likely because of interaction with relations. It’s a big vulnerability when users can just vandalize whatever they feel like and we have to resort to fixing things by hand. As the data quality and density grows, protecting the validity of that data will become more important and more difficult.
SomeoneElse
@Q The lower population density of the US is often used as an excuse, but in that location (just north of NYC) it surely isn’t a valid one. US mappers, as a whole, don’t seem to be as keen to “get out and map stuff” as some other places around the world. Obviously that’s a gross generalisation, but there’s some truth in it. People have speculated that it’s in part due to the old TIGER import of some spectacularly inaccurate data; I’m not especially convinced by that.
On the “tools” question, “simple” reversions through JOSM usually work without conflicts if done quickly, and even if conflicts occur it’s not _that_ difficult to resolve them – the problems usually occur if no-one notices a problem for months. When that fails, there are still options – raising it on IRC or even asking a help question (where there are copywrite issues the extra redaction tools that the DWG have may be needed; but even that’s only an email away).
What we really need to finally resolve problems like the stray node that you spotted is not “better tools” but “more surveying mappers” – currently apart from the rogue shop Washingtonville has two schools but no other POIs at all. NYC’s not a mapper-free area either – “neis-one” shows 7 new mappers in the last week within what I’d consider a travellable distance of Washingtonville.
The big OSM-US conference is in NYC this summer – one really great legacy that could leave would getting people surveying their local areas.
JBJ
The color change is a cruel joke. Maybe its an improvement in heavily populated areas that don’t even use Landuse tags, like London. But in rural areas where buildings are sparse they vanish into the background.
“It is better” is not an argument for making it worse to see.
DaCor
The building colour change is fantastic and long overdue. “Nearly invisible” buildings are the norm now. OSM previous rendering was so 2007. Im actually really sad they kept the old colouring at higher zooms, it looks amateurish
As for the tagging change, change is good. Resisting change for the sake of resisting it make little to no sense. I’d likely wager the people resisting most have probably not done a pipeline edit in a seriously long time and also do not make use of the pipeline data in its current guise. Like I said, resisting for the sake of it
I like to think of it as a whiny drummer deliberately playing to the beat of a death metal track while the band plays a ballad
Minh Nguyễn
DaCor, are you sure the old color was kept at the higher (closer-up) zoom levels? I’m seeing the new color up to z19, except where the tile server hasn’t caught up yet.
Harry Wood
I get uncomfortable with sudden style changes because of the backlash it always attracts. Also you get a period where the rendering servers are trying to catch up. So at the moment the building look more subtle and grey, but if you zoom in on some patches, some of the zoom level 18/19 tiles are still cached with brighter purple buildings. This only lasts a few days, and might seem like a fun quirk of the rendering systems if you know what’s going on, but it’s not a very good experience for map browsing end users.
I keep trying to suggest that style changes should be made gradually, moving to a new colour by shifting over a period of a many months. For example lots of people were annoyed when abandoned railways were dropped from the rendering. That would’ve attracted less fuss if they were just gradually getting paler and paler.
But making buildings less bright is a good change.
Richard Fairhurst
“I like to think of it as a whiny drummer deliberately playing to the beat of a death metal track while the band plays a ballad”
Thing is, death metal is so much better than soppy balladry.
I’m not sure where this question gets us other than navel-gazing. Is there anything that I’d like to see changed? Yes. Lots. So I’m working on changing it. You?
RobJN
Richard, I’m not sure who that last bit is targeted at but I don’t feel that either myself or DaCor have to justify ourselves. Sure I can’t contribute to any software development but I do enough in other ways. Happy OSMing 🙂
Richard Fairhurst
It’s not targeted at anyone in particular, nor was I asking for justification!
For both of the examples you cite, we have plenty of ideas circulating on the lists. It would be a bit facile of me to say that ideas on the lists – or on blogs, or on Twitter, or wherever – don’t make things change. In theory they could lead to change.
But in OSM they very, very rarely do. That’s not particularly a failing of OSM, it’s just how our community has evolved. What works is putting a prototype out there (whether that’s software or something else) and attracting people to your cause.
In both the above cases, there’s a prototype just screaming to get out – and neither is software development per se. openstreetmap-carto right now is caught between serving the “old Mapnik” and “old Osmarender” markets. Some people want it to be a lovely-looking showcase style, others want a comprehensive mapper-focused style: you only need to look at the issue queue to see that. It’s not a tension that can be trivially reconciled. Could a New Osmarender work – rendered with Mapnik, naturally, but aiming for completeness in a way that a general-purpose render will never do? Prototype it and find out.
Same goes for the tagging question. You or I can spend 300 words here discussing a solution (it’ll probably be documentation) but it doesn’t achieve anything, and nor will it lead to anything being achieved. Better to spend that time quickly knocking up a prototype. If it works and people join in – great. If not, that’s lessons learned for next time.
Let’s make “more prototyping, less wibbling” a challenge for OSM in 2015.
RobJN
I agree, we’re not short on ideas. I have ideas all the time but unfortunately a working prototype is generally beyond me. At best I could do some wireframes or visualisations but this doesn’t get you much further than words.
So how do we turn ideas into reality? I see 2 options:
1. We go on a major offensive to attract new developers to OpenStreetMap which means we have to get out there with a strong positive message and internally we have to squash the negativity in some of our mailing lists so as to not put developers off.
2. We develop the OSMF (or for that matter any group that is able to fundraise) in to a central coordinator that is able to filter the ideas and progress the best by throwing resources and money at them.
I’d love to hear if you have any other ideas.
(p.s. Fred’s idea of being able to “subscribe” to change notifications filtered by topic seems like a good solution for managing change as OSM matures:
https://lists.openstreetmap.org/pipermail/talk/2015-January/071761.html
Would you like me to create some wireframes visualising this? )
DaCor
“Thing is, death metal is so much better than soppy balladry.”
I actually lol’ed picturing you in the local church banging out a bit of Cannibal Corpse on the organ.
As for change, yes, it comes in many forms and I’m working on many of them presently (OSM Ireland, #MapLesotho, OSM classes & lectures in local schools & colleges, member of 3(2) working groups, creating videos and other training guides etc) however nothing I am working on involves software development simply because I’m not a software developer.
This is a big problem in OSM, like so many things, there are good ideas and suggestions falling between the cracks because too much relies on too small a group.
Looking at a recent HOT example, they hired someone for a specific period to only work on improvements to (a) the HOT site and (b) the tasking manager interface. Maybe this is something that should be done from time to time in OSM. Bite the bullet, and spend some cash
Richard Fairhurst
Couple of interesting issues here.
Not everything that helps OSM is software development. In fact, I’d go further – core osm.org development, operations and maintenance are the aspect of our project that’s in the best health at the moment. There’s always room for improvement but it’s not where I’d choose to focus energies.
An example. I’ve probably done two things that have made a big difference to OSM: Potlatch and switch2osm. The former was development, the latter wasn’t – it was me with my publishing hat on rather than my coding hat; I had no input into the technical content of the guides (indeed, I’d never set up a rendering server when we launched the site).
There are lots of content and marketing opportunities like switch2osm – indeed, we’d identified and were progressing one before CWG imploded. That sort of work is real, helpful progress for OSM, so much more valuable than endless hand-wringing discussion on mailing lists.
And yes, there are software development needs too (I might have mentioned a mobile app one or a thousand times…) but by and large these are away from core osm.org itself.
Second point.
If you think software development is the way to go, forget about OSMF organising it, at least for the moment. OSMF isn’t capable of running a whelk stall right now, let alone employing developers. I hope the new board will fix that (though, to be honest, the rejection of term limits has dashed much of the hopes I had in them) but we would be very foolish, given recent history, to expect advances in OSM to come from OSMF.
Fortunately this isn’t actually an issue. Development can and does happen outside OSMF. iD is a terrific model: a big improvement to OSM that was externally funded but developed in consultation with the community, yet at enough of a distance that the bikeshedders couldn’t get their claws into it. It’s actually not that far from how most open source projects are developed – supportive companies pay for people (or parts of people) to work on the project. (WMF is an exception, but Mediawiki isn’t exactly something we want to emulate anyway…)
One interesting avenue that I’d be keen to explore is for some of the smaller, independent developers (independent consultants, or SMEs like Geofabrik) to form a consortium that could obtain such funding.
And a postscript:
Comment comes with responsibility too. In a volunteer-driven community, making your opinion known forcefully or repeatedly, without the willingness to back it up with actions, can have a disheartening effect on those who ‘do’. That’s what drove me out of OSMF in the CWG episode, and I’m afraid it looks like it might be happening again over in the Membership Services Working Group – excessive bikeshedding towards people who are actually putting the hours in. We need to think about methods of community interaction so that such voices are not given a prominence they don’t deserve. (To clarify, I’m not directing this observation at this posting or its comment thread!)
IOOI
Quote: “Simply grab our underlying data and render your own map using any style you wish.”
If it only were that easy. I am struggling for quite some time now to get all the software needed for a tile renderer installed. That process is still too complicated and we need to make it a lot easier before “Simply grab our underlying data and render your own map” becomes a viable option for John Q. Public. Providing ISO images with everything needed installed could be a first step.
RobJN
I wondered how long it would take for someone to pick up on that sentence! You’re right it’s not “simple”, which is one reason why http://switch2osm.org/ was established. We still have some way to go but it’s not right to hold changes back because other areas aren’t 100% perfect (especially when we have a tile usage policy anyway).
weekly 233 – 30.12.–05.01.2015 | weekly – semanario – hebdo – săptămânal – haftalık – 週刊
[…] Nickerson talks about two proposed amendments and asks how the OSM Communnity handles it. A discussion about the maturity of OSM started on […]