Open daniel-j-h opened 7 years ago
nice idea. but we would need to have all the lua lib files, and make sure they're in sync with what's really on the backend, which could be challenging.
maybe it would be better to provide an api where you post tags and get back the processed values? that way you don't need to do any lua transpiling in the browser. of course this would only allow mappers to experiment with changes to the osm tags, not the lua code, but this is what i think you intend?
nice idea. but we would need to have all the lua lib files, and make sure they're in sync with what's really on the backend, which could be challenging.
I think as long as the code is pure-lua having multiple files and modules should not be a problem. The main problem currently is the call out to C++ functions.
The idea to have it browser-based only is to make it accessible to a wider range of people without much setup or installation other than including a osrm-profiles.js.min
file :)
if it was runnig on the demo server, users would not need to install anything, they could just use the map to find an osm object, and then see how changes to the tags would affect the computed routing values.
Mappers often don't know in advance how specific tags affect the routing engine: there is the possibility of setting up a local routing engine or waiting a day or two until the demo server cycles in a new dataset. Both options are tedious and make the feedback cycle unreasonably slow, read: no one does this.
It would be great if users could get instant feedback for how their changes to osm objects affect routing.
What if we could use a browser-based Lua interpreter (there are many, transpiled via emscripten) and show the user how tag changes affect our internal (Extraction*) data structures?
We won't be able to show connectivity or issues involving more than one osm object. (At least not without implementing a small routing engine in the browser :thinking: - let's punt on this for now.) But mappers at least get instant feedback re. speeds (Is it worth it adding surface tags?), barriers (Do we handle block barriers?), etc. This would be similar to the debug map but specialized to a single osm object and on steroids wrt. responsiveness.
I think all we would need for this is to provide shims for the globals we bind in the scripting environment. Basically the same @emiltin is already doing to test Lua profiles in a standalone-fashion without a routing engine behind the scenes.
Note: this ticket is mainly about the work we need to do on our side. If we can pull this off, we should think about integrating this into existing web-based tools mappers are using.
Worth giving it a try?
cc @PedaB