Mini abstract

Quoting OSM wiki about routing…

“Checking your fix. After you have fixed an error on the map you will need to wait until the revised version of the map propagates into the routing engine you are using. This delay will depend for each engine…”,

…one of the problems in Qualty Assurance (QA) is the lag between OSM editing and update of routing databases. As far as I know, implementation takes some hours in Grasshopper and 24+ in Mapzen and OSMRM.

Hence, in trying to solve a routing problen (ie: for an interchange) testing can only be done well beyond editing time :-(

Let’s see how we can bypass this delay using an homemade router.

Choosing a router

Routino looks simple, functional and flexible. I picked out this SW because it works flawlessly even on a small device like my OrangeePi: as an example, you can route in Friuli Venezia Giulia with this live instance, updated daily. For larger areas we’d soon experience performance problems; so let’s leave global routinig up to above mentioned services and focus on a kind of patchwork on-demand…

Automating patch generation

User should be able to choose the area to debug: to achieve this (and due to my zero experience in html/perl scripts) I create a Telegram bot named Routino Patcher and a bash script to manage content.

What happens is:

• bot ask you for “Location” (from mobile device GPS or thru attachment) and triggers script;
• script runs a query [added barriers] around coordinates received which download an .osm containing highway and restrictions only [e barrier]; preset area is square 0.002° [cos(latitude) TBD];
• script performs some cleaning ops (routino “planetsplitter” tool abort if “meta” and “note” tags are found in .osm input) and updates extents of routable database (which grows upon to accomodate each requested location);
• in 30” or so, bot displays a message which comfirms routing database update (details can be found in routino data page) and a link to routino webGUI map, updated with our “patch”.

For each location sent, the related .osm is processed together with other areas previously requested [incremental update TBD]. Since this is a service wich aims to test “fresh” OSM edits, locations older than 24h are purged.

Conclusions

I know my low programming skills leaded to this dirty solution, but I needed it, hoping that in the meantime someone will find/build a service like this, already working and using a single interface :-)