Author: Patricia Szasz

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 https://improveosm.org). 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: http://osmose.openstreetmap.fr/en/map/ and https://keepright.at/.

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.

Looking from a map analyst’s 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 number of intersections between motorway, trunk, primary, secondary, tertiary, residential, and service ways from the 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 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 the 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 the 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 an unusual number of members
• “Odd” tagging in existing turn restrictions
• Conditional turn restrictions with an old tagging scheme

Example of a 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.

This kind of errors identified by us during the query-based QA can also be found on http://osmose.openstreetmap.fr/en/map/ and https://keepright.at/ 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 that 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.