abrensch

> I just liked to ask about a performance: Do you expect an enhancement with the change? Performance is not the main objective, but simplicity, readability, maintainability, test-coverage.. Keeping the...

> This is a major change I have in mind since some time now, but > it's a major step and not clear yet whether this can be a patch...

Ja, known problem that BRouter cannot handle "2-node-loops" I don't remember the exact reason for this technical constraints. But I remember that I spent some effort to *mostly* mitigate this,...

Are you talking about bikes or cars? The kinematical model for car-routing has already some symmetry-breaking, when crossing straight, the speed constraint may be different whether a street is joing...

Just a few thoughts on that: the energy display in BRouter-Web was done originally for cars, with electric cars in mind. The value is displayed in kWh and the meaning...

>> Most of the information is from reading the source or older issues, >> so maybe @abrensch can confirm if I'm correct. Ja sure, the first part is correct and...

In order to deploy the master branch as a pre-processor I had to comment out the query for hgt-style files in "PosUnifier" Reason was a performance Bottle-neck from doing expensive...

A bi-directional API to the layer-provider can get complex quickly. When attaching BRouter-Suspects, first I thought that just merging the contents of my dispatcher-page into your selection page is easy...

> 1. Simple undirected Dijkstra terminating at the desired target nodes Not target nodes, but edges (=node pairs), and not terminating, but just remembering the current cost (linearily interpolated along...

>> while there are some regressions (for construction sites where some >> mode of transport actually can pass), I believe it is much more user >> friendly to send them...