doing that.
While I managed to find time to work through the release process, I do not have
time to do any significant refactoring work :-/
daniel
On Thu, Oct 15, 2020 at 12:38 AM Julien Coupey wrote:
Hi Daniel and all
Thanks for your work on this release, and all the various recent
Hi Alex
There is probably no easy approach for this in OSRM, because the whole
speedup-through-precomputation pipeline is at the opposite of dynamic
adjustments.
Removing the regions on the fly *per request* does not seem realistic
because you'd have to go through the data treatment
Hi,
The osrm-contract command is used to create the hierarchy for the CH
algorithm. You need to use the MLD pipeline[1] to preprocess the data.
Alternatively, you can change the algorithm used in example.cpp here[2].
HTH,
Julien
[1]
Hi Didier,
The exclude flag feature introduced a while back in OSRM might explain a
change in RAM requirements for the same OSM file. If you don't need that
feature, you can disable the associated extra work/memory usage by
setting an empty "excludable" list in the profile at:
Hi Valerio,
In your example, if the 3 ordered points need to be visited in a row,
then you can easily transform your problem into a TSP by treating them
as a single "job". You'd just have to adjust the matrix by ensuring that
from any other place, the cost to that job is the cost to the first
Hi,
Not sure if you're hitting the same problem here, but I recall a related
discussion happening a while back at:
https://github.com/Project-OSRM/osrm-backend/issues/1724
At least it provides a few hints on permissions and shared memory.
Julien
Le 26/01/2018 à 18:31, Daniel Patterson a
Oops sorry, forgot links in previous message:
[1]: https://github.com/Project-OSRM/osrm-backend/issues/1623
[2]: http://map.vroom-project.org/
Le 07/10/2017 à 14:49, Julien Coupey a écrit :
Hi Sasha,
For the record, you can read the ticket[1] where fixed start/end
implementation has been
Hi Sasha,
For the record, you can read the ticket[1] where fixed start/end
implementation has been discussed.
TL;DR: the same kind of approach should allow to serve your use-case
(fix start but end at any location that is preferable for optimization).
This is how I did it myself anyway, see
Hey
A quick note to let you know that a project I've been working on for
quite some time just reached v1.0.0. VROOM is an optimization engine for
vehicle routing problems heavily based on OSRM for all table and route
computations.
If you have your own OSRM instance and want to give it a
Hi Didier,
I'm getting the same kind of result of about 503 km on a custom server
set-up with *only* the french road network. But if you look closely at
the 379 km route you get from the demo server, you'll see it goes a long
way through Switzerland.
My guess would be the second option
Hi,
This seems to be related to your web server policy (and nothing to do
with OSRM). I had the same situation a while back and solved it by
adding the following to the relevant apache .conf file:
Header set Access-Control-Allow-Origin "*"
See for example
Hi,
I have used a strategy close to what is described in the mentioned
ticket (see my comment there). It did work for another project to add
this specific feature to an existing TSP solver.
As for the "computationally expensive" side, it is all a matter of
trade-off between computing time
Hi
As I'm curious about this thread, I gave the proposed solution a try. On
the same osm.pbf data for France, I compared the default car profile
with the same profile modified with mode_ferry = 0 on line 151.
The modified profile does prevent routing through some ways tagged as
"route":
Hi,
I need to perform table queries on a few (but not all) european
countries. Extracting and preparing the whole "europe.osm.pbf" data set
is an option but I wonder if I should rather try to merge osm files to
get the smallest required subset.
So I'm wondering if performing the queries on a
14 matches
Mail list logo
