As you may already know, Telenav uses crowd-sourced OpenStreetMap (OSM) data to bring to its customers one of the best navigation services out on the market. We have chosen the OSM model, because the edits are published every minute, resulting in maps that are often more detailed and more up to date than commercially available maps.
OSM, just like Wikipedia, is the only crowd-sourced and open-sourced map of the globe and, for many developers and passionate mappers, it has become a clear alternative to Google Maps. The community has doubled year over year to more than 2.2 million registered editors, with people mapping every country around the world, ranging from the U.S. to Germany and Lesotho to North Korea. For example, newly laid streets and newly developed areas can be updated on a regular basis and in real time. In addition, OSM allows for greater map detail for pedestrians such as alleys, sidewalks, parks, hiking trails, zoos, and even city trees.
Telenav has been an active contributor to OSM for more than five years, working closely with the community to enhance specific features needed for navigation, traffic and other future location-based services.
In regards to Telenav's contribution to the OSM platform, it was more than welcome for a dedicated team to be a gatekeeper of the OSM idea. As we have an active role in the company's map data generation roadmap, we build frameworks for high frequency map updates and we analyze the map to provide an overview on the map data set and to assess the quality of the map.
So, the main challenge for us is to find the best ways to accomplish that by using internal and openly available GIS tools and libraries.
To put this into practice, we use relational database management tools like:
PostgreSQL and PostGIS to manipulate spatial data,
QGIS for data viewing, editing and analysis,
Also, osmosis, osmconvert, osmfilter and overpass turbo come in handy when we want to filter and convert data files for specific map objects. We analyze the map, searching for repeating patterns related to different bugs that exist on the map. We are always searching for new ways in which we can detect errors, in a programmatic or visual way.
Here is an example on how a mapper has to deal with a mapping job: we created a style map in QGIS that highlights the areas where there are a lot of nodes, packed close one to each other, by duplicating the nodes layer and by setting the Layer blending mode to burn, causing the nodes to become more yellow, as more nodes are overlapping in an area. We could also do this in a more programmatic way, counting the length between each segment and setting a threshold, show only the linestrings that have 10 consecutive nodes with a distance between each node smaller than 20 centimeters.
Yellow areas mean higher node density; the size of the grey circle is proportionate with the number of node edits; the green area represents the number of line edits; the dark red areas show the number of tags attached to each linestring.
Other tools that help the collaboration with the community are MapRoulette and OSM Tasking Manager. MapRoulette is a gamified approach to fixing OSM bugs; it breaks common OSM data problems into micro tasks that can be solved in no more than 3 minutes. Tasking Manager has the same purpose, to divide mapping jobs into smaller tasks. It is helpful in case of an emergency, distributing tasks to various mappers.
Some of our projects that we currently focus on are: improving the Canadian road map, maintaining the USA data and also preparing to take full advantage of the recently released road data by the Mexican National Institute of Statistics and Geography (INEGI).
The INEGI database contains spatial information regarding the administrative divisions in Mexico and road network files. The latter provides a unique ground transport network that integrates national highways and a detailed road map of all localities.
OK, but how exactly do we "exploit" this valuable resource? How can we merge the rich data that OSM already has in many places, which we obviously want to keep, with the INEGI dataset? The process of enhancing the OSM map is not straightforward. Let's have a look at an example, San Angel Zurumucapio, a small locality in the middle of Mexico. OSM has only the main traffic arteries (left image), and if we look at Bing aerial imagery (right image), it's clear that almost the entire settlement is not mapped.
In this case, INEGI has most if not all the roads in this locality in their open dataset.
In order to be on the same page, the INEGI data attributes have to be converted to OSM-appropriate tagging. Next step would be to merge the two datasets (pre-existing OSM data and INEGI) with our internal tool. The tool takes as its input a base OSM file as well as the INEGI enhancing file; it will then compare and conflate the two and propose a set of changes to the base OSM data in an output file that can be imported into JOSM.
Even though the tool does a very good job merging the OSM data with the enhancing file, a manual cross check is still needed before the final upload to avoid bugs like: extraneous edges, overlapping or duplicated roads and connectivity errors.
This kind of task, due to its size, needs a big amount of work that can't be done by a small team of map analysts, this is where the collaboration with the OSM community is vital, through deploying Tasking Manager jobs and MapRoulette tasks. If this subject caught your attention, you are more than welcome to our OSM gatherings (organized once a month) to find out more about OSM and to join this groundbreaking, collaborative effort.