Author Archives: OpenStreetMap

About OpenStreetMap

Posts written "by OpenStreetMap" were written collaboratively by the Communication Working Group and/or other OpenStreetMap Foundation folks.

Routing on

Good news for OpenStreetMap: the main website now has A-to-B routing (directions) built in to the homepage! This will be huge for the OSM project. Kudos to Richard Fairhurst and everyone who helped get this up and running.


You might be thinking, “Why would this be huge? Isn’t it just a feature that other map websites have had for years now?” Well, the first thing to note is that the philosophy of OpenStreetMap is not to offer a one-stop-shop on our main website, but to create truly open data to empower others to do great things with it. So there has already been fantastic OSM-based travel routing for many years, on excellent websites such as OSRM, Mapquest, Graphhopper, Cyclestreets, Komoot,… the list goes on and on.

But all of those things are on other websites and apps, so people don’t always realise that OpenStreetMap has this power. What this latest development has done is really neat: the OSM website offers directions which are actually provided by third-party systems, but they are included in the main site via some crafty JavaScript coding. So as well as being really handy in itself to have directions available, it helps “first glancers” to see all the things they can do with OSM.

But that’s not what makes it huge.

What makes it huge is the difference it will make to OpenStreetMap’s data by creating a virtuous feedback loop. One of the main reasons we show a “slippy map” on the OpenStreetMap homepage is because people can look at it, see a bridge that needs naming or a building to add, click “Edit” and fix it straight away. That feedback loop is what allowed OpenStreetMap to build up what is now the most complete map of many regions around the world.

But we have a saying: “what gets rendered, gets mapped” – meaning that often you don’t notice a bit of data that needs tweaking unless it actually shows up on the map image. Lots of things aren’t shown on our default rendering, so the feedback loop offers less incentive for people to get them correct. And that goes doubly for things that you never “see” on the map – subtle things like “no left turn” at a particular junction, or “busses only” access on a tiny bit of road, or tricky data issues like when a footpath doesn’t quite join a road that it should join on to. Now that people can see a recommended route directly on the OSM homepage, they have an incentive to quickly pop in and fix little issues like that. The end effect will be OSM’s data going up one more level in terms of its quality for routing. This will empower everyone to do great things with geographic data and getting from A to B.

So find yourself some directions today!


Blog post by Dan Stowell


The Latin America OpenStreetMap community was created recently and we decided to organize collective projects on subjects that are common to many countries of our continent. Our first project is Mapazonia.

mapazoniaThe Amazon rainforest includes territory belonging to nine different nations and there are a lot of environmental institutions and governments that need better geospatial data to do their work in that region. Furthermore it’s always good to have quality data in case of a natural disaster or other humanitarian issues. In Brazil there aren’t many editors in this northern region, so there are a lot of towns without any data and some roads to trace.

The Amazon is huge, it has 5 million and a half square kilometres. So initially we are defining some prioritary areas to map in Tasking Manager. There is already one activity in Brazil and another in Bolivia. The main aim is to improve the tracing of the rivers and the road coverage.

Soon we will have more areas in others countries. If you want, you can work in others areas of the Amazon. Put the hashtag #mapazonia in your changeset comments, so we can see your edits in this map.

Visit the site:, follow the twitter account @mapazonia and enjoy mapping the Amazon!

At the Edge of the License

Where the ODbL Ends and the Community Guidelines Beginguidelines_sign

In the beginning…

OpenStreetMap (OSM) is, at its core, a global database of geographic information and has a license, the Open Database License (ODbL), which is designed from the ground up to ensure freedom for publicly released databases. In spirit, it is very similar to the Creative Commons “Attribution Share-Alike” (CC-BY-SA) license, which is designed for creative works, or the GNU General Public License (GPL), which is designed to cover computer source code.

Both the CC-BY-SA and the GPL have existed for many years and are built on “copyright” laws, which allow the author or authors of a work to control under what conditions it may be duplicated. These laws have been around, in some form or another, for over 300 years and, because of their long history, have been scrutinised by legislators, lawyers, judges and juries many times. This process of scrutiny results in legislative or judicial rulings, and each of these decisions helps build up a body of “case law” and precedents that can be used later on to form an opinion on whether a particular use is likely to be challenged or not. It is important to know that decisions are only made when judges or juries give verdicts, which means that it is often impossible to make any definitive determinations without prior case law and precedents.

The extent and powers of copyright have been tried in court many times and it would seem sensible to base OSM’s license on it. However, it is far from clear that copyright would apply to a database of geographic information and so our license is based on copyright, contract law and the “database right”, which was first enshrined in law in 1996 as part of the European Database Directive. Sadly for us, open data, as distinct from the more established fields of open computer source and open highly creative works, has a set of distinct challenges, especially when share-alike licenses are involved. The “young” nature of the database right also means there’s very little history, case law and few precedents which leads to uncertainty about the implications of ODbL. This uncertainty translates into risk for the users of OSM data, which can prevent OSM being more widely used and hinders one of the project’s primary goals: allowing the data to be used in “creative, productive, or unexpected ways.

Until case law and precedents can be decided by court cases and judicial decisions we can reduce the uncertainty by clarifying the intentions of those (i.e: the OSM community) who released the data. Our consensus opinion carries a great deal of weight and can help shape the direction of any future decisions regarding the use of OSM, and possibly other open data.

The new guidelines

The Licensing Working Group (LWG) has been working hard to ensure that uncertainty is reduced for data users while the intent of the community is protected. After much discussion, in June this year the first set of guidelines was approved.


Just as copyright has “Fair Use” exceptions when the sample is not substantial, so does the database right. Whether an extract is substantial or not according to copyright depends on the relationship of the extract to the original work, as it does in database right. Unfortunately, this creates uncertainty for data users as to whether their use is substantial or not. This guideline tries to define the term “substantial” more precisely in the context of OSM. For more details, see the “Substantial Guideline”.

Produced Work

“Produced Work” is a term used by ODbL to broadly separate something created from a database but not a database itself. Because the share-alike provision of ODbL applies only to databases and not to “produced works”, it is clearly important to make the distinction between the two as unambiguous as possible. For more details, see the “Produced Work Guideline”.

Trivial Transformations

There are situations where OSM data can be manipulated or “transformed”, but in such a way that the manipulation does not actually add to or enhance the core contributions made by the OSM community. Therefore, there is no common good to be served by forcing the publication of the result of those manipulations. An example of this might be loading it into a PostGIS rendering database with osm2pgsql – no value has been added by this transformation, so we call it “trivial”. For more details, see the “Trivial Transformations Guideline”.

Regional Cuts

There are many places in the world where OSM data is the best available map data, and some where it isn’t. In regions where it isn’t, many users would like to use an alternative source instead, but are unsure whether this would trigger share-alike requirements on the whole dataset. This uncertainty prevents, in some cases, any use of OSM data, even in regions where it is superior. This guideline adopts and formalises the established principle that OSM data may be used for some regions and not others, as long as certain conditions are met. For more details, see the “Regional Cuts Guideline”.

Horizontal Layers

Just as there are many regions of the world for which OSM data is the best available, there are also many thematic “layers”, for example restaurants, for which OSM data is superior. However, the question of whether the use of additional layers from other sources is acceptable is preventing some uses of OSM data. This guideline adopts and formalises another long-established principle: that isolated layers in a map may come from OSM or not, as long as certain conditions are met. For more details, see the “Horizontal Map Layers Guideline”.

Where do we go from here?

These are just the first guidelines and there is still much work to be done in clarifying the grey areas surrounding proper use of OSM data. Specifically, work is needed to help make coherent guidelines on:

  • Metadata Layers – If a layer of externally collected (non-OSM) metadata is made and kept completely separately but matched to numbers generated by the database to identify individual elements in OSM, when is it derivative and therefore must be shared?
  • Indexing – If OSM data is indexed, for example by a search engine, is that a derivative database which would need to be shared?
  • Geocoding – If locations are found for addresses, or descriptions generated for locations, in a process of “geocoding” would that trigger the “share-alike” clause on the license and require the sharing of the data being geocoded?
  • “Fall Back” – In a service which first attempts to find an answer by looking at OSM data and, if an answer cannot be found, “fall back” to search another database, are these databases separate or does the process you are using mean that you have combined them and are therefore required to share the combination?
  • Dynamic Data – If providers of dynamic data, such car-park occupancy, use OSM data as an underlying reference source, does that require the sharing of the dynamic data?
  • Offering alteration files – When sharing a database, the ODbL says one can offer “a file containing all of the alterations…”, but is not specific. What form should this file be in?

The LWG will continue to work hard and discuss these issues with the community and data users. If you feel that you would like to contribute, then please contact LWG, join the OSM Foundation and the discussion there, or join the general legal discussion mailing list. We would love to welcome your voice and views to the conversation.

Welcoming our first Corporate Members

Back in February we described a new membership option for the OpenStreetMap foundation, and since then we’ve seen our first “corporate members” joining.

Geofabrik, Geotab, Naver, and NextGIS were the first four members, and [UPDATE] they are joined by Mapbox today:

By becoming corporate members, these organisations are generously helping to keep our servers running, supporting the work of our volunteer working groups, and above all showing their support for OpenStreetMap.

We hope to see a growing number of organisations appearing on our Corporate Members page. Thank you for your support!

20 million edits

In January 2014, OpenStreetMap saw its 20 millionth edit.osm-20million-edit

User:cosmicpop registered to edit OpenStreetMap just recently, and made a little fix to the map of his local neighbourhood. These things happen thousands of times every day, and with enough people mapping in their local area, we’re building a free and open map of the world!

But this time was special. This was the 20 millionth edit saved to OpenStreetMap. To celebrate, we decided to get in touch, and present this contributor with a prize. Here is cosmicpop with his new OpenStreetMap hi-vis jacket!

“Wow, I’m not the superstitious type, but this is the first time I’ve ever edited on OpenStreetMap, while in my other browser tabs I was looking for a hi-vis jacket to wear while cycling which I have recently taken up. Maybe I should do the lottery this weekend.” – Cosmicpop

Cosmicpop tells us he had been thinking about contributing to OpenStreetMap for a while now, and decided it was time to fix a one-way restriction which was missing from all maps. Friends visiting him were often surprised by the one-way not being marked on their satnavs. Well now it’s correct on OpenStreetMap – a great local improvement by a new user for our 20 millionth “changeset”!

Changesets? Edits?

When you’re editing OpenStreetMap you can add new map elements or modify existing ones. Your changes – be it one or a hundred – are sent to OpenStreetMap when you click “save”. Simple!

When you do this, you write a little message describing your change, and this is recorded, together with your edits, as a “changeset”. We just hit 20 million of these bundles of changes, some big, some small.

You can view your own changesets from your OpenStreetMap profile page, or view the latest changesets from all users. For a more spectacular global view of changesets as they happen, check out live OSM edits, and “show me the way“.

More stats

Of course changesets are not the only stats we track. OpenStreetMap also has…

2.17+ billion Nodes in database
214+ million Ways in database
3.78+ billion GPS points in database
1.5+ million registered users
Check out the stats page for more.

Upgrading from Google v2 API? Free yourself and upgrade to OpenStreetMap

google-v2-javascript-no-longerHave you received an e-mail like this?

“We cannot guarantee that your maps will continue to function. We highly recommend that you migrate to Google Maps v3 before November 19.”

Yes, Google Maps are shutting down their old JavaScript Map API (v2). They recommend that you spend a lot of time rewriting your code to switch to the newer v3 API.

But why not spend that time switching to something better?

OpenStreetMap is the map made by experts – the locals who know their area intimately. It has footpaths and bike paths, alleyways and waterways, green spaces and public places, along with the roads and railways you expect. It’s updated every minute of every day, not just next time Google sends out a StreetView car. No wonder big names like Foursquare, Github and Mapquest have already made the switch to OSM.

Switching from Google Maps to OpenStreetMap is easier than you think. If you’ve struggled with the old Google Maps APIs, you’ll find our equivalent, Leaflet, a breath of fresh air. Its smooth presentation will give a real lift to your site’s appearance, and on mobile it’s as fluid as a native app.

And if you want to go further, OpenStreetMap lets you build your own, beautiful custom maps from our data. You’re not limited to the same Google styling that everyone else uses. Because it’s all open source, you don’t even have to pay us anything for ‘premium’ services.

So how do you do it? The OpenStreetMap community runs the website which offers several recommendations for switching to using OpenStreetMap. Check out the ‘Basics’ and ‘Using Tiles’ sections to find how to switch your JavaScript to OSM. If you want to build your own custom maps, you’ll find full details there too.

Because ultimately, OpenStreetMap is much more than a Google Maps API replacement. We offer something rather different: free and open access to raw map data. This empowers developers to unleash a wave of innovation and creativity which goes beyond embedding maps on a website. Best of all, when people use OpenStreetMap on their websites, more people see the map; more people join in with mapping efforts; and the community-created map gets even more detailed. By using OpenStreetMap you are supporting it, and helping us with our not-for-profit mission to create the best free and open map of the world.

iD In-Browser Editor Now Default on OpenStreetMap

The State of the Map 2013 venue in the new iD editor

The State of the Map 2013 venue in the new iD editor

If you click the edit button today on OpenStreetMap, you will find a new, easier to use in-browser editor.

With OpenStreetMap rapidly becoming the go-to map for thousands of mobile apps and websites, more and more users are seeking an easy way to add their local knowledge to the map – without the technical background of OpenStreetMap’s early adopters. The new all open source web editor, named iD, was launched last May as an additional option to make the editing experience much easier for first-time mappers.

Since then, the iD developers have worked hard to close feature gaps and improve performance such that it can now take its place as the default editor for iD offers a walk-through tutorial for first-time users, inline documentation for tags, and a more comprehensive help system than previous in-browser editors.

Potlatch, the existing online editor, continues to be developed for intermediate-level users and will remain as an option in the edit dropdown. For a full list of available editors, take a look at our wiki. You can configure your personal default  in your user settings.

Head over to and give the new editor a spin.

Skobbler Throws Support Behind New OpenStreetMap Infrastructure

Skobbler has pledged €5,000 to help fund improvements and new additions to the infrastructure powering OpenStreetMap. As part of the summer OpenStreetMap Infrastructure Funding Drive, this donation will help the Operations Working group add an additional core server to improve redundancy, add additional routing and tile servers, and extend the hardware contingency fund that kicks in when repairs are needed. The full spec on what infrastructure will be covered in the funding drive is here


Skobbler has made significant investments into OpenStreetMap this year, sponsoring the upcoming State Of The Map conference as well as the SOTM U.S. and SOTM Baltics local conferences. OpenStreetMap is a fundamental piece of Skobbler’s work – they use OpenStreetMap data to power location-based apps and services for mobile devices. You can read more about their work and see the apps they’ve built using OpenStreetMap.

A big thank you to Skobbler for helping improve OpenStreetMap’s infrastructure! The infrastructure funding drive is wrapping up this week, so it’s your last chance to pitch in to this fund-raising effort. Help us scale our infrastructure to support our rapidly growing map and users. Donate here

Extending the OpenStreetMap Infrastructure Funding Drive

There’s been an amazing response to the OpenStreetMap infrastructure funding drive launched last month. Given the incredible enthusiasm for strengthening OpenStreetMap’s core infrastructure, we’ve decided to extend the funding drive so we can do even more and do it right.

We’re now asking for an additional £32,500 / $50,000 that will allow the OSM Operations Working Group to make hardware purchases and build out our server set-up. This increase in capacity will open the doors to even more growth of our lively community, and ensure that map editing will always be available.

You can help us now by donating online or contact us.

Where Your Donation Goes

Phase 1: Cost £40,000 / $60,000 (Achieved!)

  • An additional master database server to improve reliability and performance.
  • A new central file server for greater capacity.

Phase 2: Cost £32,500 / $50,000 (Help us fund this!)

  • Routing servers (more details on this to come)
  • Tile cache servers in NA for faster loading tiles.
  • Off-site backup improvements so that, in the event of a disaster, OSM will be back up quicker.
  • Additional database read-only servers for greater speed and responsiveness.

Your contributions will directly improve the single most important piece of infrastructure for OpenStreetMap. Thanks for your support and for helping OpenStreetMap continue to grow and become faster, more reliable, and more powerful.
You can donate now at or by contacting us.

Funding Drive reaches 70% – thank you MapBox!

Thanks to MapBox who have pledged a $20,000 donation towards our fund raising drive.

MapBox provide tools for designing and hosting stylish maps using OpenStreetMap data. They’re bringing our maps to an impressive range of customers and end users. Meanwhile MapBox developers have driven progress in several important open source development efforts within the OSM ecosysem including of course the recently launched iD editor. They’re also big supporters of OpenStreetMap.US and the SOTM US conference. If you’re attending this (in just a few days now) you can thank them in person for this donation pledge.

Ever played one of those games where completing a task brings up an “Achievement Unlocked” message? Well, MapBox’s donation pledge is contingent on the fund raising goal being reached. So our task is to raise the remaining 30% and unlock the funds for OpenStreetMap’s new hardware.

For any questions around larger contributions, please contact the OpenStreetMap Foundation.

Why do we need this new database server? Simply because the growth in OpenStreetMap contributions is outpacing what our existing machines can handle – it’s a good problem to have. The new machines will handle our explosive growth for at least the next 12 months, giving our hard-working, dedicated operations volunteers time to plan for continued growth in the future.

You can read more on the MapBox blog