CrowdAtlas: Self-Updating Maps for Cloud and Personal Use

Motivation:

The authors of this paper wanted to create a solution for the inaccuracy introduced in manually creating digital road maps.  They also noted accuracy issues in persistent maps and the ACM GIS conference emphasized auto map correction as one of the top open problems.  Another citation “A British insurance survey found 26% of drivers had been directed by their GPS to go through no-entry signs or prohibited areas. 

In response to this problem found in a very valuable resource, they created CloudAtlas; an automated map update system based on real time GPS track or historic GPS tracking data.  These updates could be performed on an individual basis or through crowdsourcing.  CloudAtlas generates new additions to maps when GPS tracks do not match underlying roads and corrects existing ones where inconsistency is present between tracked routes and current map roads.  

 

Main Points:

• They wanted to create a system that automatically updated a map server and/or a local navigation app.  This was handled through dynamic sampling where matched routes were sampled at a lower rate and unmatched routes benefited in a dynamically increased sampling rate for higher accuracy in road generation.  The server is able to handle heavy computation methods over the mobile phone, so local confirmations only require a single track and user confirmation for additions whereas the server requires multiple tracks going over the same road to generate a cluster of enough tracks to be above the required threshold to generate a new route.
  
• They claim to have a novel combination of map inference with navigation map matching that allows for high accuracy, real-time map updates, including heavy customization improving upon their prior algorithms for inference and matching.
  
• Demonstrated value through mapping new roads in a 4.5km² area generating 61km of roads, in  Shnaghai Pudong district, to contribute to OSM.

Trade-offs/Influence/Comments:

• The main focus of this paper is around the inference of missing roads, which is the task the authors consider to be the most challenging among all updates that CrowdAtlas provides.
• There was an inconsistency of chosen threshold mentioned in this paper between 3 and 4.  It isn't a major point, but might be something that was actually important depending on the types of routes that they were inferring (pedestrian/arterial/etc.)  If the threshold was lower you increased the probability of inferring roads from noise and it also creates greater position error.
• In the case of walking, GPS signals tend to have less significant noise.  The faster transit speed of driving allows the device to acquire and loose GPS connections more rapidly creating a jittered GPS signal, especially in urban jungles.
•  The authors always mentioned that there was minimal overhead introduced over the regular running of  GPS navigation software, but they never supplied any real numbers to this.  I am curious if the incremental method for the current best candidate is what is already used for placing your position on maps or if this is more demanding in the ways that they are utilizing it?
• Since most people do not immediately traverse the same route again, it would be interesting if they could weigh the pros and cons of a delayed server update of unmatched nodes.  Currently it pushes it upon returning to matched roads as a batch, which already allows for a reduction in power consumption/transfer cost, but I could easily see having a higher frequency of unmatched roads in rural areas where connectivity isn't present or is very slow - thereby severely effecting energy consumption.
• Would roads get reclassified based on a discrepancy in speed along with the ways they already mention adjusting existing roads: direction and GPS points?
• Instead of having a future work section, these authors chose to spread their comments about further improvements throughout the paper.
• They mentioned that there were more ways that could be implemented to determine type.
•  Matchmaking is a  bottleneck.
• Data loss is possible on failure, but as mentioned in the paper, it is not seen as a problem, and by the nature of their application, it is shown to not be a concern.
• They highlighted ways this would be challenging and time consuming to perform without a base map, but I would be curious to see what maps their application and server combination could work without the aid of a preexisting base map.