Route planning for mapillary

Has anyone got a good way to plan a route to capture images for Mapillary that is automated and create the shortest route possible to cover every street in an area. I could manually plan a route but would be excellent for this to be automated. reverse phone lookup Wish it was built into OSMAnd but a way to generate a GPX would be fine.

Maybe it could be done in PG_Routing.

This has been asked a few pcpartpicker times in the Mapillary forums but not seen any automated way to do it.

My reason for capturing the images is to then use them to update OSM.

1 Like

This is pretty much the definition of Traveling Salesman Problem - lots of points and finding optimal route. PgRouting has specific functions for it.

There are some tricks in preparing the data. Using “raw” OSM data won’t do, because then you can only create routes which use every node. So every edge has to be split with new node in the middle and TSP has to be run with all those new nodes as input. If driving both ways is necessary, then splitting must be done twice with new cost and reverse_cost values set as if it is one-way road.

Now I don’t have a working example at hand, but probably still have code somewhere which I tried to use for winter maintenance modeling. However, using the principles described above, it’s not difficult to recreate.

1 Like

i wouldn’t call that automated

First step would be to find (or create) an OSM derivative map that did a map-matching process of Mapillary images, so a coverage indicator of images on that road for each OSM-road-segment can be calculated.

Based on such public map, several routing algorithms could be applied to generate a route (with e.g. only roads with 0% or low percentage mapillary image coverage).

I can not imagine the team did not a kind of map-matching thing yet? Maybe they can create and publish a public OSM-based map with mapillary coverage included?

Let’s start with Turbo Overpass and Mapillary.

I don’t think there is a map matching link between osm data and mapillary data. They are separate datasets, and the only kind of matching I can think of is low tech “compare raster images of a mapillary coverage layer and osm roads”. is able to map uploaded sequences on road level (no overlay with image dots).

Also, tomtom is able to map match live gps userdata and show delays on road level. Map-matching technique is available for years