The Future of Map-Making is Open and Powered by Sensors and AI

The tools of digital map-making today look nothing like those we had even a decade ago. Driven by a mix of grassroots energy and passion combined with innovations in technology, we have seen a rapid evolution marked by three inflection points: the dawn of consumer GPS, availability of high-resolution aerial imagery at scale, and lastly a shift to large scale AI powered map-making tools in which we find ourselves today.

Automatically detecting salient features from open street-level imagery could accelerate map-making by a factor 10

For OpenStreetMap (OSM), the availability of affordable and accurate consumer GPS devices was a key enabler in 2004, when Steve Coast and an emergent community of trailblazers (literally!) biked around, captured GPS traces, and created the first version of the map using rudimentary tooling.

The wide availability of high-resolution, up-to-date aerial and satellite imagery became the next map-making game changer around 2009-2010. It empowered people worldwide to contribute to the map, not just in places they knew, but anywhere in the world where imagery was available. This led to the rapid growth of mappers worldwide and the further expansion of a global map, aiding notable humanitarian support efforts, such as the enormous mapping response immediately following the 2010 earthquake in Haiti.

Fast forward to today, and we find ourselves in the midst of yet another massive change in map-making, this time fueled by the ubiquity of sensors, artificial intelligence (AI), and machine learning (ML). The three-prong combo of the availability of mature software frameworks, a thriving developer and research community, and commoditized GPU-based hardware enable an unprecedented wave of AI-powered technology for consumers as well as businesses.

It did not take long for the map-making community to harness this power and begin applying it to ortho- and street-level imagery to automate the generation of observed changes to the map. When directed to the human mapping community, these outcomes will reduce, without a doubt, the effort to create and enhance maps by a factor 10.

At Telenav, we have jumped on this trend early building and growing OpenStreetCam as have others with a stake in OSM, such as Facebook.

An important element, however, has been holding back a more rapid adoption and perfection of machine learning-based map generation: the lack of openness in the space. For various reasons, both data and software have largely been kept in silos and have not been open to contributions by the community. In our view, creating an open ecosystem around new map-making technology is vital – openness and creativity are what made OSM a success in the first place, because mappers could capture what they deeply cared about.

We are convinced that an open ecosystem around machine learning for map-making is the only way to ensure that this technology can be embraced and appropriated by the community. To that end, Telenav is opening up three key components of the OpenStreetCam stack:

  • A training set of images. We have invested more than five-man years creating a training set of street-level images aimed at common road signs. The set consists of well over 50,000 images, which will be available to anybody under a CC-BY-SA license. We will continue to manually annotate images to double this set by the end of 2018, by which time it will be the largest set of truly open images.
  • Core machine-learning technology. Currently, our stack detects more than 20 different types of signs and traffic lights. We will continue to develop the system to add features important to the navigation and driving-use cases, such as road markings including lanes.
  • Detection results. Lastly, we will release all results from running the stack on the more than 140-million street-level images already in OpenStreetCam to the OSM community as a layer to enhance the map.

You can find everything mentioned above in the Telenav.AI repository on Github.

Our hope is that opening our stack and data will enable others to enhance both the training sets as well as the detection nets and put them to new, creative uses that fulfill the needs and wants of the diverse mapmaker and map-user communities.

Additionally, by openly licensing the data and software, we want to make sure that the next era of mapmaking with OSM remains open and accessible to everyone and fosters the creation of a new generation of mappers.

To celebrate this milestone and to empower the community to run their own improvements to this stack on suitable hardware that is otherwise cost prohibitive, we are kicking off a competition around our training data and software stack, aimed at improving the quality of detections.

The winners will be able to run their detections on our cloud infrastructure against the more than 140-million images currently on OpenStreetCam, and of course release the improved and enhanced detection stack for all mappers to improve OSM. (Oh, and there’s $10,000 in prize money as well!!!!)

In the longer term, we will be releasing more parts of the map making technology stack that we are building to further enable OSM’s growth and expansion, and in order that it plays, over time, a central role in powering autonomous driving.

So, stay tuned for more from Telenav!


Map Metrics for OSM are now available

Telenav’s OSM team just released a portal where you can view different metrics on OSM.

Unlike other metrics views that are already available, this new tool for the OSM community is focused especially on navigation attributes like length of navigable roads, number of turn restrictions, signposts and many more, in total 22 of such metrics are available. You can check it out at

About the data

Metrics are computed weekly and should be available on the portal at the end of each week. Metrics are generated for the whole world using as input the planet pbf downloaded from the official mirrors made available by OSM community

Metrics are available starting with 8th February 2016. In the top left corner, you can choose to see them by week, by month or by quarter. We also have a nice feature for all OSM enthusiasts! For each metric in the left menu you have a small info button where you see exactly what the metric means: complete description and the rules we applied when computing them, which tags where used, if we counted ways, nodes or relations etc.

How do we do it?

The platform was built using Apache Spark. Using big data technologies enabled us to have metrics for the whole world: on countries, states, counties and a few metropolitan areas (metros are available only in North America for now). In order to use Apache Spark, we had to convert pbf to parquet first, so we achieved this using a parquetizer that is open source and can be found here.  After we have the parquets, using Spark’s DataFrame API we managed to have these metrics available in just a couple of hours.

We have also made the latest parquet files available for general use here.

If you have any suggestions or feedback, please do not hesitate to contact us. You can find details in the About section.

Happy mapping!


New version of OpenStreetCam JOSM plugin with sign detections

This post also appears on my OSM diary.

The Telenav OSM team just released a new version of the OpenStreetCam JOSM plugin. The major new feature is the ability to show and manipulate street sign detections. Images in only a few areas are currently processed for sign detection, so it’s not very likely that you will see anything yet, but that will change over time as we catch up processing over 140 million images.


To enable detections, right-click on the OpenStreetCam layer in the Layers panel, and check ‘Detections’ under ‘Data to display’. You can filter the detections by the following criteria:

  • Not older than — show only detections (or images) from that date or newer.
  • Only mine — show only detections / images from my own OSM / OSC account.
  • OSM Comparison — show detections based on comparison with OSM data:
    • Same data — Only show signs that have corresponding tags / data already mapped in OSM
    • New data — Only show signs that do not have corresponding data in OSM and need to be mapped
    • Changed data — Only show signs that have existing tags in OSM but the value is different (for example a 50 km/h sign and the OSM way is mapped as 60 km/h)
    • Unknown — No match could be made between the detected sign and OSM data
  • Edit status — show detections based on manually set status of the detection:
    • Open — new detection, status not changed yet
    • Mapped — manually marked as mapped
    • Bad sign — manually marked as a bad detection
    • Other — other status
  • Detection type — show only signs of the selected types.
  • Mode — Show only automatic detections, manually tagged detections, or both.

For the filters OSM Comparison, Edit status and Detection type, you can select multiple values by using shift-click and command/ctrl-click.

In the main editor window, you can select a sign to load the corresponding photo, which will show an outline of the detected sign. If there are multiple signs in an image, you can select the next one by clicking on the location again. (This is something we hope to improve.)


In the new ‘OpenStreetMap detections’ panel, you can see metadata for the detection, and set the status to Mapped, Bad Detection, or Other. By marking signs that are not detected correctly as Bad Detection, you hide them from other mappers, and we will use that information to improve the detection system.

The plugin is available from the JOSM plugin list, and the source is on Github.


Geohash JOSM plug-in

The Telenav OSM team has a new JOSM plugin for you: Geohash. This plug-in displays a layer on top of the JOSM map that contains the corresponding geohashes, up to zoom level 10. It also allows searching for a specific geohash and moves the map to the corresponding area.

Our team has been using this plugin internally and thought it may be useful for some of you as well.

This plug-in can be used by those who work in specific areas based on geohash units.

How to use the Geohash plug-in

The geohashes are automatically generated based on the user map view and zoom level. Increased zoom means increased depth level for geohashes.

To search for a geohash, use the Geohash plug-in dialog. Type or paste the geohash code in the text field and press the Search button. If the code is invalid, a message will be shown. Otherwise, the map view will be moved and zoomed over the selected geohash.

To clear generated geohashes, double click a geohash and all geohashes from his parent will be cleared. Also, right click on Geohash layer will show the option to ‘Clear geohashes’ that will leave only the depth one grid.

You can find the source code here:

We are looking forward to your feedback!


Working with ImproveOSM Data Dumps

Our ImproveOSM pipeline produces a pretty impressive number of suggested roads missing from OSM, missing oneway tags, and missing turn restrictions, based on analysis of billions of GPS data points. We make the results available as frequent data dumps in CSV format. In this post, I want to look at a way to integrate this data into your OSM mapping workflow.

If you just want to see ImproveOSM data in JOSM wherever you are currently mapping, you can just use the ImproveOSM JOSM plugin. For advanced users who want more flexibility, or who want to use this data in different ways, this post offers some guidance.

The data dumps are available from here. For this example, I will work with the most recent Direction of Flow data file. This highlights ways with potential missing oneway tag. After downloading and unzipping it, you will have a CSV file of about 16.5 megabytes that looks like this:

148617028;1867720648;89191396;99.5378927911275;SOLVED;THROUGHWAY;LINESTRING(2.217821 48.922613,2.217719 48.922618,2.217408 48.922633);1082
33555379;322840377;322840383;98.6301369863014;INVALID;LOCAL_ROAD;LINESTRING(4.999815 47.34294,4.999957 47.343062,4.999965 47.34315);146
17271190;178942503;2341050872;100;OPEN;LOCAL_ROAD;LINESTRING(11.070503 50.139245,11.070525 50.139213,11.070616 50.139099,11.070693 50.139032);74

Since the theGeom field is in WKT, you can import it as a layer in QGIS pretty easily. Let’s fire up QGIS (I use 2.18) and add a Delimited Text layer.

In the dialog, select the downloaded CSV file as the file source. Set the delimiter to semicolon. QGIS detected for me that the geometry was in the theGeom field, and of type WKT, but you can set that manually if needed:

Upon clicking OK, QGIS wants us to define which CRS the coordinates are defined in. Select WGS84.

Now, we have a layer of line geometries that correspond to OSM ways that may be missing a oneway tag.

To make the file more manageable, let’s limit our selection to one country. I get country boundaries from Natural Earth (a fantastic resource!). After adding the country borders to QGIS, I can perform a spatial query. Before you do this, select the country you are interested in. I pick Mexico as an example.

Bring up the Spatial Query window. If you don’t see this menu item, you will need to enable the Spatial Query plugin.

Select the ImproveOSM layer as the source, and the Natural Earth layer as the query layer. Make sure to check the ‘1 Selected geometries’ checkbox, so we limit our query to Mexico.

The matching features will now be selected in the ImproveOSM layer. Make sure that layer is selected in the Layers Panel before you select Layer -> Save As.. from the QGIS menu. In this dialog, choose GeoJSON as the output type. Select a destination filename. Make sure that the CRS is set to WGS84. Make sure the ‘Save only selected features’ is checked, and Save.

Now you have a GeoJSON file with all OSM way geometries that may need a oneway tag. You can load this file into JOSM, using its GeoJSON plugin. To organize your work going through these, I would recommend using the Todo plugin and add the GeoJSON features to the todo list.


Detecting Traffic Signs in OpenStreetCam

OpenStreetCam’s mission is to help you improve OSM with street-view imagery. Photos taken with regular smartphones seem to be good enough for capturing map features like traffic signs, lanes or crosswalks. However, browsing the 120 million+ photos in OSC to find relevant things to map will take a while. The human factor is fundamental to OSM’s culture and we don’t see that changing, but we want to make editing street related attributes more efficient with automation.

We’re happy to announce a beta release of the traffic signs recognition on OpenStreetCam photos, made possible with machine learning. We processed a few million photos and detected around 500.000 traffic signs so far, currently available for tracks in several areas in United States and Canada. We’re working on extending the training sets and optimize the processing so that the area’s soon expanded.

What’s new from a user perspective: the track page on will now show detected traffic signs when available:

There’s a preview list of all detections in the track, detection overlays on photos and, of course, filters. Filters might now get a rep as something really exciting, but we’re excited about one of ours: the OSM status. Here’s why: after detecting a sign we compare it to the corresponding OSM feature and check if they’re consistent. Based on that, filtering is available.

For a practical example, let’s take speed limits: Instead of manually cross checking every detection with the maxspeed tag in OSM, one can only review detections where presumably maxspeed is not set or the value’s different in OSM. Just tick the Need review in OSM box.

Here are a few more examples of trips that have already been processed with our sign detections.

What’s next?

We’re busy working on a few things:

  • Scale the training sets and pipeline to extend the supported areas.
  • Traffic signs integration in the JOSM plugin.
  • Tagging new traffic signs support in the webpage.

If you like what we do and want to help:

  • First and foremost, you can use detections to improve OSM. If you’re seeing detections on tracks check them out, see what needs reviewing in OSM and edit. You can open iD or JOSM to photo’s location straight from the webpage.
  • Help us improve the traffic signs recognition. There’s a chance you will find some bad detections. You can review them and flag whether they’re good or bad, see the two buttons above the photo. We’re adding those reviews to training sets to improve recognitions, so please play nice.
  • Help us add these detections to the iD editor as well.

Tip: you can navigate between detections with Ctrl/Cmd + right/left arrows and confirm/invalidate with Ctrl/Cmd + up/down arrows. Goes pretty fast.


Making OSM navigation ready in Phoenix, AZ

GPS technology is growing fast along with the mapping industry. There are a lot of navigation apps on the market, trying to step forward using different technologies and map data. As you know, behind all its routing processes and algorithms, a good routing application must have a good quality map.

Our team, Telenav, is developing an Open-Street-Map (OSM) based app, called Scout. Why Open-Street-Map? In my opinion OSM is a good choice because it’s an open, fast growing and well built-up community map. With its great involvement and commitment, the community is constantly trying to keep all the map features from OSM up to date.

For the purpose mentioned above, Telenav decided to improve the quality of the OSM map features, used for navigation, in Phoenix, Arizona.

From September until now, the whole project workflow was realized in 3 main steps:

Step #1. Research and get in touch with local community (research on local open source data, keep in touch with local OSM users, official traffic signs and driving rules, research on HOV and toll roads, roads under construction, other specific road features of Arizona State).

Step #2. Build-up process:

  1. Road geometry, Road Name, One Way, Gates and Other Geometric Feature (turning circles, turning loops, etc.)
  2. Signpost
  3. Turn Restrictions and Traffic Lights
  4. Lane and Turn Lane Info, including HOV Lanes and Toll Roads
  5. Speed Limit Editing

Step #3. Quality Assurance (QA for every feature edited by our team in OSM, some road name special issues, repairing broken relations, final edits and corrections based on Improve OSM plug-in, Osmose and Keep Right errors, tile-by-tile verification).

The first step was a very important one because the team had to get in touch with the local community and mapping rules. Also, we researched other open source and free of charge data beside the already well-known sources used by OSM users (TIGER Roads, Bing, Digital Globe, Open-Street-Cam, Mapillary). The under-construction roads found in this step were permanently monitored, to be edited later.

The second step was the most time consuming and it included the editing and reviewing of all the most important navigable OSM features, starting from motorway, trunk, primary, secondary, tertiary, residential and service ways. The whole editing process lasted for about 3 moths and the workflow was mainly based on a tile-by-tile method. We also edited based on way category or route reference. During this period, we helped the community to increase the OSM quality as you can see below:

The third step was the last but not the least important. Because we wanted to have good quality features in OSM, we had to make a closure check on our edits, already made in the build-up process and where it was necessary, to fill the gaps. So, we used different QA procedures, queries, other plug-ins, error identifiers and even tile by tile verification.

For the queries based QA, we ran some predefined scripts based on OSM datasets, using pgAdmin and PostgreSQL. The queries were aimed mainly at finding:

  • Wrong one-way direction
  • Wrong number of lanes
  • Untagged roads
  • Long relation members
  • Turn Restrictions with unusual number of members
  • Ramp has name or reference number
  • Similar names and destinations
  • Detect possible roundabouts, etc.

The main JOSM plug-in used to complete the missing roads was Telenav ImproveOSM (also available on The plug-in focuses especially on missing roads, one ways and turn restrictions.

Also, a good source of errors to be checked can be found on these error identifier sites: and

Doing the QA, we had an important overview of all our edits, especially of our wrong ones. In this step, we resolved also a name tag issue we’d came across during step #2. Step #3 represents confidence of a good quality editing process for the Telenav team.

When we needed a double check of our work, the community was a good help, giving us important feedback. For the next months, we’ll surely keep in touch continuously with the local OSM users, looking forward for their feedback to keep up a good maintenance work. The top editing users were the most helpful users, giving us precious and pertinent feedbacks.

In the GIF below you can see an evolution of Telenav mapping team edits during the last moths, in Phoenix, Arizona. Darker colors indicate high density and brighter colors low density.


Turn restrictions editing in Phoenix, AZ

Looking from a map analyst point of view, turn restrictions are some of the most important features a map can have. Turn restrictions influence a lot the way a route is made. If they are wrongly edited, they can cause bad routing, having big consequences on travel time, travel directions, maneuvers and so on. That’s why we decided to talk a little bit more about this case: editing turn restrictions.

We worked on this issue for 3 months, starting from November 2017. We succeeded to review a large amount of intersections between motorway, trunk, primary, secondary, tertiary, residential and service ways from Phoenix area.

During our project we accomplished:

  • to add new turn restrictions
  • to correct some of the damaged ones
  • to remove some of the wrong ones.

The main sources of adding or editing turn restrictions were open-source:

  • Satellite imagery: Digital Globe, Bing, Esri World Imagery
  • Street level imagery: Open-Street-Cam (OSC), Mapillary.

The software used in editing OSM was JOSM, an extensible editor for Open-Street-Map for Java 8. Also for a better visualization we used different Map Paint Styles (MapCSS) and thematic Layers (Open-Street-Cam, Mapillary, Mapillary object layer).

With a self-developed procedure, we identified all that could be a turn restriction sign in all the OSC track photos, overlapping our area. In the first part of our project we looked over 1723 turn restriction signs identified in Open-Street-Cam, spatially distributed as in map below. Before adding any turn restriction, every detection or sign found in Open-Street-Cam was first validated based on the open sources first mentioned.

In the second part, we managed to identify turn restriction signs also based on Mapillary Imagery and Mapillary Object Layer.

All the reviewed turn restriction signs summed in the end 3289, from which 350 turned to be missing from Open-Street-Map. During this task we also reviewed 11932 and added 376 new traffic lights.

The final step for our task was to do some QA testing. Firstly, we used a query based QA to verify the quality of all turn restrictions from OSM Phoenix area. For this, we ran some predefined scripts based on OSM datasets, using pgAdmin.

The queries aimed mainly:

  • Long relation members
  • Turn Restrictions with unusual number of members
  • “Odd” tagging in existing turn restrictions
  • Conditional turn restrictions with old tagging scheme

Example of query used to identify unusual turn restrictions from OSM:

We wanted to make sure we’re covered all turn restrictions. So, we used the Telenav ImproveOSM plug-in in JOSM. The plug-in highlights the possible turn restrictions locations based on road geometries and other probe data.

These kind of errors identified by us during the query based QA can also be found on and sites. These two sites contain datasets with all kinds of errors from OSM. The datasets were downloaded, extracted using some Python scripts, clipped after our bounding box and filtered using some SQL queries in pgAdmin. The results were exported and compared with the initial errors resulted in the first QA step and where it was necessary, the turn restrictions were modified or corrected.

The heat map below presents all the turn restrictions edited by the Telenav team, from November until now, in Phoenix. Darker colors indicate high density and brighter colors low density.


New Features and Enhancements in Cygnus+

Cygnus is the Telenav Mapping conflation tool. We use it a lot internally to compare approved external data sources with existing OSM data, but there is also a public version. We outlined how it works in an earlier blog post. In this post, I want to highlight some of the newer features in Cygnus. These new features are based on the feedback from our team of Map Analysts, who use the tool in their day to day work.

Discarding Very Short Segments

Cygnus outputs the differences in geometry between existing OSM data and the spatial data that we want to use to improve OSM. Sometimes, when the differences are very tiny, Cygnus used to export very short ways. These are not really meaningful enhancements, and clutter up the result data. Therefore, we implemented a length filter. Ways shorter than a defined length threshold will not be included in the output. Based on experience, we set the default to 5 meters. In the internal (command line) version our team uses, this can be tweaked using a parameter. In the public web version, this is not yet possible. We can consider adding it if there is sufficient demand.

An example of Cygnus in action. It finds an opportunity for improvement (possibly incorrect street name) as well as a false positive (degraded road geometry)

Road Names

When comparing road geometry, Cygnus not only compares geometry, but also road names. An annoying side effect we noticed is that road names are often not exactly the same in OSM as they are in the external data we compare with. This does not mean that the external data is necessarily better. For example, OSM could say that the name of a road is “River Road”, and the external data source could say it is “River Rd”. This is not a meaningful difference, and we would want to exclude those in most cases. So we added a string distance based  threshold in Cygnus to filter out similar strings. It is set to a sensible default which, again, can be tweaked in the command line version we use internally, but not yet in the web version.

Another Cygnus improvement related to road names is to ignore name differences on certain types of ways: roundabouts and service roads. Roundabout ways in OSM do not have names by convention, unless the roundabout itself has a name, so they should generally not be added. Service roads technically can have names in OSM, but it is not common. In external data, they do sometimes have names, but if they do, it usually does not make sense to add them to OSM. Based on our experience, they often have descriptive names like ‘driveway’ or ‘access road’ in the source data.

Using Cygnus

You can use Cygnus yourself by going to and uploading your source data file. You need to do a fair amount of work to prepare the source data: translating the source attributes into valid OSM tags, and converting to OSM PBF. And always remember to consider carefully what you do with the result. Cygnus is not designed to be an automated import tool. Every suggested change should be manually reviewed.

Let us know how you have used, or would like to use Cygnus!


Cygnus – conflation at your fingertips!

This is a follow-up blogpost after the State Of the Map US 2017 conference held in Denver.

The process of conflation in GIS is defined as the act of merging two data layers to create one layer containing the features and attributes of both original layers.

Cygnus is a tool that compares external data with OSM, giving you a result file in JOSM XML format with all the changes. The comparison is made in a non-destructive way, so no OSM ways are ever deleted or degraded.


NOTE – The license compatibility between the local data file and OSM has to be taken into account before adding anything in OSM. Also, please follow the OSM import procedures if you are planning to add external data to OSM.

First of all you need to have a shapefile with local data in WGS84 spatial reference. This shapefile has to be filtered in different ways, depending on the tags you want to compare. For example, if you want to compare oneways, make sure to have a flow-direction/oneway/etc. attribute in the shapefile.


The first thing that has to be taken care of is to assure a proper attribute translation. I created a simple example for this exercise. I don’t want to get neck-deep in too many technical details so the main focus remains the process as a whole. I kept the attribute information for this example straightforward:

In order to create an OSM file from this data, I wrote a simple translation file that will be used together with ogr2osm.

Next, run the below command to obtain the OSM file.

python simple_streets.shp -t -o simple_output.osm

Finally, I converted the OSM file to PBF using osmosis, because Cygnus requires a PBF file as input.

Cygnus goes to work!

Now that you have gone through the pre-processing of the local data file, we can offer it to Cygnus for processing. Note that your upload needs to be small-ish – the spatial extent needs to be smaller than 50×50 km and the file needs to be 20MB or smaller in size.

The interface of the Cygnus service is very simple – there are just two pages:

  • the home page where you add new jobs
  • the job queue page where you can see your progress and download the result

If your input file was uploaded successfully, Cygnus will go to work. Your job will be added to the back of the queue. When it’s your turn, Cygnus will read your PBF file, and download the OSM data for the same extent, using Overpass API. It will then compare your upload with the existing OSM data and produce the output file that you can download from the job queue.

NOTE – Everyone’s jobs are listed here, so be careful not to touch other users’ stuff.

Process the output in JOSM

Once Cygnus gives us the output, we can open it in JOSM and inspect it. This is by far the most important, and time consumig, step. Even though Cygnus does a best effort to connect ways where needed, it acts conservatively so it will not snap ways together that do not belong together.

Here are a few ways that got properly connected to the existing highway=secondary:

But there are situations where the distance was too far so Cygnus did not snap:

In this case, you need to manually connect the ways if that is appropriate.

When you are finally satisfied with your manually post-processed conflation result, you can go ahead and merge it with the OSM data and upload it!