lxbarth's diary

  • Rss

Recent diary entries

OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

Posted by lxbarth on 13 March 2014 in English (English)

OpenStreetMap is published under a share-alike license, the so called Open Database License (ODbL). The license says that if raw OpenStreetMap data is mingled with raw third party data, and the result is used publicly, you are required to release the result under the same ODbL. This is, in short, the share-alike principle under which OpenStreetMap data is available today - under certain circumstances, it extends the license of OpenStreetMap data to data sets it's mixed into.

Sounds like a great idea at first, right? You're promoting the idea of opening data by making sure anyone who uses your data opens their data too. Well, there's a big gotcha: we wind up more often with OpenStreetMap not being used rather than with previously closed data opened up. This in turn hurts the project which thrives on increased adoption.

Photo: Alan Levine

Organizations or individuals who want to mix OpenStreetMap data with third party data often can't because they aren't in a position to make licensing decisions on that third party data. The reality is that opening data under a specific license is usually too slow or plain not possible.

Often times confusion about what's allowed and what is not allowed under the ODbL is just as bad. Ever seen advice opening with "I'm not a lawyer, but..."? That's what I'm talking about. Ever tried to get an actual lawyer to provide guidance on the ODbL? That's what I'm talking about. Tried to use the OpenStreetMap Wiki to learn about how the ODbL is interpreted by the licensor, the OpenStreetMap Foundation? That's what I'm talking about.

The result is that OpenStreetMap is not being used in situations where it should be used, which undermines a project whose success depends on increased adoption.

Not only is OpenStreetMap not being used as much as it could, the assumption that share-alike encourages contribution is a myth. I have yet to meet the individual, company, non profit or government agency who contributes because that's what the license calls for. And I have yet to witness the troves of data opened under the ODbL in compliance with the license. OpenStreetMap gains no extra benefit from share-alike. The reality is that OpenStreetMap is only used extensively in situations where the share-alike license does not apply, for instance, map rendering.

Here are examples of what should be possible with OpenStreetMap but is not because of share alike:

The Wheelmap community manages wheelchair accessibility information for over 400,000 thousand places in OpenStreetMap. Ideally Wheelmap would be able to syndicate this data into any other map - think Nokia, Google, Apple. Today they can't because of share-alike limitations of the ODbL. Woulnd't people using this data on Google maps mean more people with an interest to maintain and improve it on OpenStreetMap since they would know that adding data to OpenStreetMap means adding it to all the maps in the world?

Currently, New York City building and address data is being imported into OpenStreetMap (disclaimer: I'm involved). Ideally the government of New York City would just copy changes from OpenStreetMap to help maintain their own datasets - but they can't. Many datasets managed by government behind closed doors today should just be managed by the same maintainers on OpenStreetMap tomorrow - with gains for everyone. Think of the US Census Bureau whose TIGER data we're all benefiting from. This vision of citizens and government collaborating around OpenStreetMap is severely cut short by the ODbL. Governments will never use OpenStreetMap in an extensive way until they can make it part of their workflow, and as long as the ODbL taints any data that touches it, it can't. Look at the United States - many government datasets are public domain, government can't use OpenStreetMap directly because the ODbL is not compatible with it.

And what about exchanging data with our big sister project Wikipedia? We should be copying a lot more data back and forth between OpenStreetMap and Wikipedia. OpenStreetMap could be Wikipedia's geocoder and gazetteer. And yes, if it wasn't for Wikipedia's own share-alike license, we could mine Wikipedia for addresses, phone numbers, home pages, and populations without a bad conscience. Wikipedia can't use OpenStreetMap because OpenStreetMap is not truly open, and OpenStreetMap can't use Wikipedia becuase it is not truly open. What better examples of two sucessful open data projects are there than Wikipedia and OpenStreetMap - but we are not open enough for our data to touch? This makes no sense.

If we dropped share-alike, nothing would stop players like Google or Apple from mixing OpenStreetMap data extensively into their mobile maps. And this is a good thing. OpenStreetMap's opportunity is not to compete and win against the Google Maps of the world, but to say what's on their maps. With adoption on established mapping platforms OpenStreetMap would instantly reach many millions of users with its data, drastically increasing the project's impact and playing a bigger role than stale backfill. OpenStreetMap's current licensing is stunting our growth - and diminishing the impact of all of the amazing data that we have.

Under the current license, these example cases are either outright impossible, or require time, good lawyers and programmers to avoid share-alike to infect third party data with the ODbL. The ODbL imposes unnecessarily onerous hurdles at no gain for the project. Worst of all, just the license's ambiguities kill adoption.

If OpenStreetMap is to turn into the data set that makes geo data a true public good we have to drop share-alike. Let's make OpenStreetMap data actually open.

OpenStreetMap is at the verge of being the dataset that powers the world, quite literally. What's between where we are today and making OpenStreetMap the source for global geographic data, is that OpenStreetMap simply can't be used in many applications where it would be the ideal solution. These lost opportunities matter because they are what keeps OpenStreetMap from having the impact it should have. As Serge Wroclawski succinctly argued in his essay on why the world needs OpenStreetMap, OpenStreetMap's purpose is to democratize who decides what's on the map:

Every time I tell someone about OpenStreetMap, they inevitably ask "Why not use Google Maps?" From a practical standpoint, it's a reasonable question, but ultimately this is not just a matter of practicality, but of what kind of society we want to live in.

OpenStreetMap simply won't matter if it doesn't power the applications that millions of individuals use to search, navigate and contextualize each day. The more OpenStreetMap is used, the more impactful each of our work is, and the more incentives we create to join the movement. We should not be afraid of that.

For your reading pleasure: Here's are the entire 4,000 words of a license we should be throwing out: ODbL 1.0. I will be speaking about this topic at the State of the Map US conference in Washington DC. Join the conversation here or on Twitter.

Propose a session for State of the Map US by February 2 (this Sunday)

Posted by lxbarth on 30 January 2014 in English (English)

Share what you've been working on, or present your vision for OpenStreetMap at this year's State of the Map US in Washington DC April 12 - 13.

You have until February 2nd (this Sunday) to submit your session.

You'll find the submission form here:

Looking forward to hearing from you.

Presentations at State of the Map US 2013. Photo: Justin Miller.

Restarting the New York City Building and Address Import

Posted by lxbarth on 20 November 2013 in English (English)

This is an update on the ongoing import of New York City buildings and addresses. For background read up on New York City and OpenStreetMap cooperating through Open Data

At our kick off session past month in New York City, we've discovered issues with the data conversion that are fixed now and the import is ready to start over again.

We have taken the time to take a close review of existing uploads. Here are some issues we've found that are worth highlighting as we restart the import.

  • Make sure every upload to OpenStreetMap completely validates and all critical warnings are resolved before you update.
  • Critical warnings are at least any warnings or errors that stem from
    • Buildings overlapping with buildings
    • Buildings overlapping with other features they cannot overlap with such as roads
  • Resolve not only buildings duplicate with existing buildings but also addresses duplicate with existing addresses
  • Merge point of interest information from existing nodes to new buildings when they clearly building-level such as schools, fire houses, super markets, etc.

To get started head over to the tasking manager carefully (re) read instructions and grab a task.

Make your life easier and get these JOSM styles for buildings and addresses by emacsen. They'll allow you to see issues with the data better. Learn how to install them in JOSM docs.

If you have any questions, fire away here on the comment thread.

Location: Little Italy, Manhattan Community Board 2, New York County, New York City, New York, 10013, United States of America

What is the OpenStreetMap convention? Do we tag addresses on buildings or on separate nodes?

Posted by lxbarth on 25 October 2013 in English (English)

On the imports list I recently raised the question on whether to tag addresses on buildings ways or not. Specifically, if there is only one address for a given building polygon, should the address tags sit on the building's ways or should the address tags sit on a separate node within the building? Obviously, if there is more than one address per building, there is no other way but mapping them as nodes separate from the building way.

Eric Fischer just ran an analysis to figure out what is actually the current convention in OpenStreetMap. Here's the short answer: addresses are tagged on building ways where possible. By a wide margin.

Read on for the numbers.

Address tagged on building ways (left) is the more common approach in OpenStreetMap versus address tagged on a separate node (right).

The rough numbers break down like this:

  • 10 million buildings carry addresses on the way.
  • 3 million buildings contain one or more address nodes.
  • 4 million address nodes sit within a building.

So the maximum theoretical number of buildings with a single address node is 3 million minus 1. Contrast this with 10 million buildings with the address information on the way. This still assumes one crazy building containing one million address nodes and it does not discount redundantly tagged addresses in the case of POI nodes that duplicate the address of the building they sit in.

Here are the full numbers (OSM planet, September 25 2013):

Buildings                                           91,917,857 
Buildings with address on way                        9,386,811
Buildings that contain one or more address nodes     2,960,363
Address nodes within a building                      3,858,096
Address nodes that are not on or within a building  10,135,036
Addresses on a node of the building way                673,975

(An address node is defined here as a node that contains an addr:housenumber tag and is not part of a building way.)

Good or bad?

For now, I'll personally stick to this convention as it's established. For the same reason I also want to stick to it for the ongoing New York City building and address import.

In principle though, I question tagging addresses on building polygons. It's a special case with no benefits while separate address nodes would work in both, the case where there are multiple addresses per building polygon and where there is only one address per building polygon.

Of course, we might also need address polygons :p.

First buildings and addresses in New York City

Posted by lxbarth on 15 October 2013 in English (English)

Last Saturday we officially kicked off the NYC building and address import with a community session hosted by OSM-NYC and Public Labs at the Pfizer building in Brooklyn. The goal was to get the local NYC OSM community involved in this large data undertaking and at the same time harden our import process.

Over 20 people attended, and we knocked out 158 of the over 5000+ sub-tasks total. Both turn out and tasks accomplished were great and exceeded what I expected for a casual Saturday afternoon event.


We've also discovered an address formatting issue and a geometry conversion issue that put the import on hold until they are addressed.

Working through this import we're learning very interesting lessons:

  • OSM data structure is significantly different from traditional GIS, nailing down conceptual differences when translating to OSM takes time.
  • Importing is a high inertia problem, partly due to sheer volume but also due to the lack of a solid tool chain like safe roll back tools or established conversion tools.
  • Expect interesting quality issues in your source data. NYC data for instance has inconsistent address formatting in the source.
  • Doing a fully automated import is non-trivial. For example, in NYC, buildings often intersect with misaligned TIGER roads. That's one big reason this import is not fully automated.
  • Once all data is uploaded, we'll need a QA check on inconsistent data to catch any errors introduced by humans during the upload.
  • This all feels a little like heart surgery.

Here are a couple of pictures and screenshots from the Saturday event. If you'd like to get involved drop me a line. Again, the import is on hold until a couple of issues are sorted out, but you're welcome to join.

screen shot 2013-10-13 at 11 55 18 pm


screen shot 2013-10-13 at 11 42 21 pm


screen shot 2013-10-13 at 11 52 14 pm

Location: Clinton Hill, Brooklyn, Kings County, New York City, New York, 11205, United States of America

Why I'm running for OpenStreetMap US again

Posted by lxbarth on 4 October 2013 in English (English)

Because I love it.

Open data is changing the world. OpenStreetMap, as a true open data project of the commons, is proving its viability with continuously growing contributor numbers and expanding adoption. We're well under way to replace what has been historically the realm of governments and proprietary-data companies with amazing open data that is not better because it's cheaper, but actually provides fresher and more detailed data because it's open and community driven. It's exciting to be a part of this in my job as data lead at MapBox, as an individual contributor and as a board member of the OpenStreetMap US chapter.

This last year on the board of OpenStreetMap US has been amazing. Working together with Jim, John, Randy and Martijn on the board and with the great support of community members like Kathleen Danielson, Bonnie Bogle and Ian Dees, we've brought the organization to a new level. We're honing in on our goal to not only promote OpenStreetMap in the United States, but to make it bigger, stronger and more diverse. Here are some of the things we've accomplished:

For the next year I want to stay 100% focused on continuing to grow OpenStreetMap in the US and beyond. I am convinced we can do this only by uniting the many voices of our project and by being as open and inviting as possible to newcomers. This is why it will be so important to nail our conference again. The importance of State of the Map US for the growth of OpenStreetMap cannot be overstated. It is the main tool we have to convene our community, pull in new individuals and institutions and discuss the future of the project. OpenStreetMap brings together interests from very different backgrounds: it's being used and improved by individual mappers, businesses, governments and nonprofits. Individuals work with it as data consumers, data producers, software developers, designers and researchers. This diversity is exactly our strength and is exactly what we need to continue to grow OpenStreetMap.

I would love your vote for pushing on this vision on the board of OpenStreetMap US.

OpenStreetMap US elections are running from October 5th to October 12th, to vote, you simply need to be a member of OpenStreetMap US. Signing up only takes a minute, find out all details about the election over on the blog.

OpenStreetMap colored by contributor id

A Social Without Groups

Posted by lxbarth on 24 September 2013 in English (English)

There has been lots of talk about groups on lately. In early 2013 Mikel called for better social tools, including groups on OpenStreetMap, and lately more often groups have been mentioned as a replacement for our ailing mailing lists. Saman had a version of groups in his blue sky mockups for Tom's posted a sketch for groups as pull request.

I'd like to add a dose of skepticism in this discussion: I don't think we should implement groups on right now, there are better alternatives to get started with if our goal is to make OpenStreetMap more social and let mappers connect better.

Here's why:

  1. Most conversations ideally don't require groups.
  2. It's hard to do social software right, groups in particular.
  3. Social media platforms are distributing.

(1) Most conversations ideally don't require groups

When you stop to think about it, groups are a crutch. They require you to set up a space with a topic and name (even if it's just a couple of clicks), then people need to find it, subscribe to it and sustain interest in the group. If the group doesn't go well, it bleeds members and lives on as a distracting zombie. Ideally, you'd be able to have conversaions ad-hoc around a certain topic or locality. That's one reason why you don't find groups at all or in a dominant role on some of the most successful social networks today.

(2) It's hard to do social software right, groups in particular

What was the last forum or groups software you used that didn't suck? Right. It's hard to do groups right on an interaction design level. I personally haven't seen general group discussion software ever done right, but what I do know is this: whatever we embark on means significant investment - or falling short on expectations. The risk to wind up with another level of noise in our already brittle social space is real.

(3) Social media platforms are distributing

Today OpenStreetMap enthusiasts gather in spaces on mailing lists,, Twitter, Facebook, forums, and Google Groups. Whatever we build competes in this space. Right now, we shouldn't attempt to build the better replacement for all of this, but think of as a compatible layer, allowing mappers to bring OpenStreetMap into their respective social online environments with ease.


Instead of introducing groups as a large new feature on I suggest we fix current social functionality on This would vastly improve how mappers connect on a local and global level and would allow us to take an iterative approach, giving us real returns at each step, building on firm, well known ground. Here's a first back log:

  • Great opt-out email notifications for edits, diary posts, comments of who you're following and posts you've commented on.
  • Make it much easier to see who's mapping in an area
  • Introduce public wall-style messaging, allowing conversations in the open.
  • Ideally shut down private messaging to avoid abuse (which is happening according to administrators).
  • This is small: Rename 'friend' to 'follow' - because that's what it is, no one confirms a friend request on OpenStreetMap.
  • Kill the home location feature including the map on the profile
  • Replace the useless friend listing and 'in your area' listing on your profile with a list of latest edits by who you're following
  • Encourage users to link to local groups from their profile (Facebook links, links, mailing lists links, wiki links, etc.)
  • Possibly: vote up (down?) comments on diary.

Each of the above steps is small compared to implementing groups - still, each one will require dedicated work. Together they are designed to move us forward in a solid fashion from where we are right now. And note: some of the features like notifications could come in handy if we still wanted to introduce groups at some later point.

So what about our mailing lists?

Done right, the above improvements will already take important weight off of our mailing lists, we should iterate from there. With improved notifications and commenting on diaries we'll have much better spaces for meaningful discussions. I assume that much of our outcome oriented work will continue to move to GitHub. It's also going to be interesting to watch how Map Club will move in this realm. In addition, I suggest evaluating, a promising new discussion forum by Jeff Atwood the maker of Stack exchange.

What do you think?

Disclaimer: I am offering this simply as food of thought for those who're interested in pushing on social features right now. From a MapBox team perspective, we're not queueing up any immediate work on the social features mentioned here.

A new way of fast browsing of latest changes

Posted by lxbarth on 2 May 2013 in English (English)

Finding out fast who's modified the map is hugely valuable to review changes in areas you care about, to connect to new mappers or to just show how fresh the map is.

Unfortunately, the part of that's supposed to provide this functionality - the history tab - is functionally broken. I'd like to suggest here a straightforward way to fix it, punting on some of the hard engineering problems that fast browsing of historic changes bring with them.


To recap if you're new to the issue, here's why the history tab doesn't work today: virtually anywhere in the world you'd like to see the latest changes of a particular area on OpenStreetMap, what you'll actually get is large-scale changes whose bounding box happens to intersect with with the area on the map you're viewing while not actually impacting any data in the area you're viewing.

This is a well known problem in OpenStreetMap and people like Matt Amos, Ian Dees and more recently Paweł Paprota have worked on coming up with a solution for this issue.

The underlying engineering problem is Hard: changes to OpenStreetMap are organized in changesets, each one of which can contain up to 50,000 edits and whose modifications can be geographically huge. Querying all changesets that actually modified data in an arbitrary bounding box of the world and displaying them in reverse chronological order is computationally expensive while at the same time it should happen in milliseconds to satisfy a web request and allow for fast browsing.

Fixing the history tab

At the Chicago hack weekend Tom and I created a prototype that completely punts on the expensive problem of fast browsing for the entire changeset history. The approach we've taken is essentially to present you with a map and a list of the latest changes on visible elements first, then only reveal the history of an element when you click on it.

Conceptually, this is very straightforward and supported by existing APIs, computationally this is dirt cheap. This is not actually a novel approach in OpenStreetMap (most editors do something like that) but it is viable as an alternative to today's history tab.

The prototype doesn't do any data processing itself and is actually just a simple HTTP and JS application hosted on Github pages. It uses the OpenStreetMap API's map call. The latter means it is querying OpenStreetMap in an unefficient way, but this is a comparatively simple problem to fix. It could just as well query a very simple tiled data source.

Check out the result for yourself. I think it is already a very useful browser for exploring changes on OpenStreetMap. With few iterations this could be much faster and a viable fix to OpenStreetMap's history tab.

Related conversation on [dev] list can be found here:

LearnOSM Relaunched

Posted by lxbarth on 21 March 2013 in English (English)

We just relaunched LearnOSM - the step by step resource for learning OpenStreetMap. LearnOSM was launched in 2011 by the Humanitarian OpenStreetMap team for the workshops they are giving world wide. It has grown into a resource used by OpenStreetMap newcomers and trainers well beyond its roots in humanitarian aid and disaster risk management.

Read up on the new LearnOSM and learn how to contribute to translations and other improvements by Jue Yang, the designer and developer behind the new face of LearnOSM:

Spot checking the openstreetmap-carto style

Posted by lxbarth on 19 December 2012 in English (English)

Andy Allan recently ported the OpenStreetMap standard style from pure Mapnik XML to CartoCSS and TileMill. This is exciting as it's a huge step towards making contributing to the style more accessible. The port is nearly perfect and kinks are being worked out right now. I took a minute to spot check and pull together a couple of screenshots showing just how close this awesome piece of work is. I hope to see this go up soon on Andy's port wouldn't change anything about how tiles are being rendered on OpenStreetMap, all that changes is how the style for those styles would be created: In the future, we'd use TileMill and generate the Mapnik XML from user friendly Carto CSS.

Here is San Francisco in the new OSM-carto port, just looks like the existing map:


For spot checking I use the comparison app that Ian and Tom cobbled together using OpenStreetMap US servers and It shows the existing OSM Standard style to the left (I'll just call this style 'OSM' for the remaining post) and the new port to Carto CSS on the right (I'll call it 'OSM-carto' for the remaining post). Note: right now it's slow / down as performance problems are being figured out.

What follows here is a quick log from my review, others have been busy spot checking, too, head over to the issue queue to find out more.

School labels are different

School labels aren't bold in the new OSM-carto style. This has been fixed in the meantime.

OSM (existing):

OSM-carto (new):

Complex junctions

Complex junctions seem to be rendering great with roads correctly rendered on top of each other and labels placed well.

OSM (existing):

OSM-carto (new):

OSM-carto has halo on secondary

OSM has no halo on secondary, while OSM-carto does have one in orange (see Castro street label) #25.

OSM (existing):

OSM-carto (new):

OSM-carto has no halo on tertiary

To the contrary, OSM has a white halo on tertiary highways where OSM-carto has none #24.

OSM (existing):

OSM-carto (new):

Label placement seems to be slightly different

This might be due to slightly stale data and generally doesn't seem to make a difference in terms of cartographic quality. In this difference rendition between the OSM and the OSM-carto style you can see how all labels seem to be offset by a certain factor and some street labels are placed at different positions along the way.

Low zoom levels

Low zoom levels look almost perfect at quick inspection. I do not know where differences in labels (see Sapporo for instance) come from.

OSM (existing):

OSM-carto (new):

Mid zoom levels are almost 100% the same

OSM (existing):

OSM-carto (new):


Differences in landcover order

There are some known differences in the order of land cover. This is being worked out right now in #15. Here is an example where the difference in landcover order surfaces in the visual result.

OSM (existing):

OSM-carto (new):

Test driving iD

Posted by lxbarth on 14 December 2012 in English (English)

Stoked about test driving the great work of Tom, Richard, John, Saman and others on the new iD editor. Here's a quick screenshot. You can get started yourself with iD fast, just clone the repo, point your browser to the index.html file in it and get started editing. Note that if you'd like to upload your changes to the test server, you'll need an account on it. Report any bugs you're finding on the issue queue.

Videos of Nov 24 Webcasts Up

Posted by lxbarth on 26 November 2012 in English (English)

Back From Intro Workshop with NYC Community at Foursquare Headquarters

Posted by lxbarth on 24 September 2012 in English (English)

We're on the bus now heading back from New York City to Washington DC after an eventful week (read about the $575k Knight awarded Development Seed for OpenStreetMap work on the MapBox blog).

Here are some pictures of the OpenStreetMap intro workshop Ian and I held yesterday at foursquare's headquarter's. Thanks to the NYC OSM community leads Liz, Serge and Eric for the initiative and promotion.

Thanks to David Blackman of foursquare for kindly offering foursquare's great digs in Manhattan for this workshop. Join the OSM NYC Meetup Group if you'd like to stay in the loop on all things mapping NYC.

A great crowd of about 30 people turned out for the workshop.

Kicking off with examples of the many ways of how OpenStreetMap data can be used.

We quickly went hands-on and started editing and improving data on OpenStreetMap using JOSM.

Ian showing how to build quick OpenStreetMap based maps using Migurski's shapefile extracts and TileMill

Liz Barry explains how DIY aerial imagery can be used in OpenStreetMap

And yeah, the view from foursquare's office is killer

Location: SoHo, Manhattan Community Board 2, New York County, New York City, New York, 10013, United States of America

In Tokyo for State of the Map 2012

Posted by lxbarth on 29 August 2012 in English (English)

kkaefer, ajashton and myself will head to Tokyo for State of the Map.

We'll arrive on Wednesday afternoon and head out on Monday afternoon. Hotel TBD. On Saturday, I'll give a talk about how we're improving OpenStreetMap with Foursquare.

I'm looking forward to meeting / seeing many great people. Drop me a line if you'd like to get in touch ahead of time.

Calle Tokio in Mexico City

Location: 駒場通り, Shibuya 1-chome, Shibuya, Tokyo, 153-0041, Japan

September 22nd: OSM intro workshop in NYC

Posted by lxbarth on 23 August 2012 in English (English)

Come out to the OSM introductory workshop in New York City on September 22nd 2012.

We'll start form square one, with an intro to OSM and its data, learning JOSM, using OSM resources and more. This clearly targets new comers to OSM mapping, but if you're a seasoned mapper, you should come out too. The NYC community is just reviving and there are lots of priorities to discuss and new people to meet. Of course, we should have drinks after (where TBD).

Find out all the details and sign up on the NYC OSM Meetup group.

Thanks to Liz Barry for organizing the event.

I am looking forward to see you there!

Location: Flatiron Building, Manhattan Community Board 5, New York County, New York City, New York, 10010, United States of America

OpenStreetMap workshops with Ônibus Hacker in Rio de Janeiro

Posted by lxbarth on 21 August 2012 in English (English)

For documentation's sake: a couple of pictures from OSM workshops in Rio de Janeiro's Cidade de Deus and Complexo do Alemão with Ônibus Hacker, around the Rio+20 Conference for Sustainable Development in June.

Cidade de Deus - street signs

Cidade de Deus - jotting down location and name of points of interest

Cidade de Deus - splitting up our survey areas with Walking Papers

Cidade de Deus - bike path

Cidade de Deus - not quite a point of interest

Cidade de Deus - the hacker bus

Cidade de Deus - the survey team

Complexo do Alemão - dense footpaths

Complexo do Alemão - cable car

Complexo do Alemão - shot from the cable car

Complexo do Alemão - the survey team

Location: Cidade de Deus, Zona Oeste do Rio de Janeiro, Rio de Janeiro, Região Metropolitana do Rio de Janeiro, Rio de Janeiro, Southeast Region, 22770-334, Brazil

Mapping Northern Uganda with the American Red Cross

Posted by lxbarth on 20 August 2012 in English (English)

The American Red Cross and Humanitarian OpenStreetMap Team called on Volunteers to Map the Ugandan Cities Gulu and Lira on World Humanitarian Day

Mapping at the American Red Cross Headquarters yesterday. On the screen a video message from the team in Uganda.

A good two dozen mappers followed HOT's and ARC's call to help map Gulu and Lira as an effort to improve maps for fire fighters and rescue teams.

GeoEye has provided improved satellite imagery that State Department helped process and host for the event. About two dozen volunteers helped trace roads, tracks, buildings and huts from imagery. As a next step the American Red Cross will send a team of trainers to Uganda to initiate necessary ground surveys verifying tracing work and to teach Quantum GIS skills for using OSM data.

You can still join the effort by picking up tasks from one of the two HOT OSM Tasking manager jobs:

For any questions around this effort, get in touch with Robert Banick from the American Red Cross.

Further reading

Location: Penn Quarter, Washington, District of Columbia, 20004, United States of America

Después del Taller de OSM en Mexico DF - Wrapping Up and Next Steps

Posted by lxbarth on 13 August 2012 in Spanish (Español)

(English further down)

Gracias a todos por atender al taller de OpenStreetMap Mexico DF el viernes y el sabado pasado. Huracán Ernesto hizo que nos quedamos adentro, pero de hecho eso fue excelente, como así pudimos enfocarnos de manera muy profunda en las herramientas de OpenStreetMap.

Ahora, mantengamos el impulso! Como resultado del evento Vitor George abrió una lista de correo para México: talk-mx, suscríbete aquí para mantenerte en contacto! Planificamos unos talleres parecidos alrededor de Desarrollando Latinoamerica que tendrá lugar en varios ciudades Latinoamericanos el 1 y 2 de Diciembre. Mandame un mensaje si estás interesado en ayudar a organizar, impartir, programar o diseñar.

Muchas gracias a Telmex Hub por equipo, lugar y promoción el evento. Tanto a nuestros amigos del Citivox, SocialTic y Fundar que hicieron posible este evento.

Aquí algunas fotos, una lista de enlaces y temas de los cuales hablamos y algunos usuarios que atendieron. También veanse estas fotos de fotografía aerea del domingo en el Chapultepec.

Hasta muy pronto!


Thanks everyone for coming out to the Mexico City OpenStreetMap workshops on Friday and Saturday. The fact that Hurricane Ernesto kept us inside I think was a good thing as it allowed us to do a great deep dive into doing OpenStreetMap work.

Let's keep the momentum going now, as a result of the event, Vitor George has initiated the talk-mx list, I encourage you to sign up! We're planning on similar OpenStreetMap workshops around Desarrollando Latinoamerica on December 1st and 2nd, please get in touch if you are interested in organizing, teaching, promoting, designing or programming for this event.

A big thanks goes to Telmex Hub for hosting the workshop and promotion and to our friends and partners at Citivox, SocialTic and Fundar for promoting this event.

Here are a couple of pictures from the workshop, a list of useful links we've talked about and a links of some of the OpenStreetMap users who were present. Also check out these balloon mapping pictures from Sunday.

Vitor explaining Relations

Saturday's training Photo: Karla Lopez

We did breakout sessions for introductory classes. Photo Karla Lopez

Temas y enlaces

Unos cuantos temas y enlaces de Viernes y Sábado. / These are a couple of links around topics we've talked about on Friday and Saturday.

Listas de correo


Enlaces de usuarios que dejaron su información. Iré agregando en cuanto sepa de los demás. / These are the links to attendees' user accounts who I've managed to gather, I'll add as I get word from the others.

Location: Centro Urbano, Ciudad de México, Cuauhtémoc, Ciudad de México, 06010, México

Balloon Mapping Mexico City

Posted by lxbarth on 13 August 2012 in Spanish (Español)

Este domingo salimos al Bosque de Chapultepec para volar un globo del excelente Balloon Mapping Kit del Public Laboratory. Encuentra aquí una pequeña historia de fotos de este día. La idea era de sacar fotos aereas, no fue tan exitoso como nos hubiera gustado...

Haz click en las fotos para ver más información.


This Sunday we went to Chapultepec park to fly a balloon (using the excellent [Balloon Mapping Kit of Public Laboratory. See here a pictures of the day. The idea was to create areal imagery, it didn't quite work out that way...

Click on pictures for more info.

Location: 1a. Sección del Bosque de Chapultepec, Miguel Hidalgo, Ciudad de México, 11100, México

Taller OSM Mexico DF Agosto 2012

Posted by lxbarth on 9 August 2012 in English (English)

Eric and myself will be leading a MapBox training and OpenStreetMap mapping party in Mexico City tomorrow, Friday (10) and Saturday (11). On both days we will meet at the Telmex Hub in the center of Mexico City. You can find all the details on our blog.

In preparation, I've done some research in areas of Mexico DF we could be focussing on. The weather might not be cooperating, scroll to the bottom to see our plan for if we're stuck with rain.

Ground surveys

Here are a lot of areas in Mexico DF that we could survey with Walking Papers and GPS. I've pulled a bunch of them together based on what I see missing on the DF map, not knowing these areas myself. Let's pick ones that are busy and safe enough. Please add more where you see fit.

We should also figure out whether we can/should get bikes or cars for the survey.

(Click to go to see map on

Around La Raza

Around Camarones station

Area around Casco de Santo Tomás IPN

(Just south of the Camarones area described above)

Around Bandojito

North of Aragón

Peñón de los Baños

West of Iztacalco

Around Juanacatlan

The missing street names are due to the redaction process.

Around San Joaquín

This is just north of Polanco

Inside activities

There's a good chance of rain - if we can't do a ground survey (some rain shouldn't stop us) we have a backup program:

Location: Centro Urbano, Mexico City, Cuauhtémoc, Mexico City, 06010, Mexico