Talk:Strategic working group/New Routing services Guidelines Proposal

Some comments on the new routing services guideline: It is great to see the proposal move along, however I think it is important to clarify what its aim is. It was clearly modeled strongly along the tile services guideline and it makes sens as a "new routing services" proposal.

However, there is a key difference between the tile layer and the routing situation. While there is an infrastructure on osm.org to accept new tile layers (the tile layer switcher), the same is not true for routing. There currently is no routing front end on osm.org and no default routing backend so far.

So what we need for routing is imho something slightly different. As the code isn't fully written yet, and assuming SWG decides it wants routing on osm.org, then we need a way to motivate developers to finish off the code of integrating the equivalent of OpenLayers and the layer chooser into osm.org, together with a workable default backend. One of the best motivating factors for developers is if there is a clear commitment that their code will get deployed if it meets a specific set of requirements rather than despite all their effort getting ignored and going to waste.

So imho we need to define a clear and objective minimum set of requirements that if a patch meets those requirements it will get deployed. Those requirements are presumably two fold. One for the front end code integrating things into the rails port and two for the default backend. The latter might look like: "Needs to support turn restrictions, needs to handle car and bike routing, may not play funny games with connectivity heuristics, must run 10 routes per second on a 48Gb machine" or of similar sort.

Once there is a routing layer on osm.org, we can then create a new routing services guideline to accept further (external) routing services.