Re: [OSRM-talk] 'penalty' for snapping
Use a wrigglefactor: Say a persons needs to deviate from straight line with a factor of: - x 1.2 on flat land - x 4.0 in mountains and swamps and calculate with a walking speed of: - 4.3 km/h road - 3.5 km/h in fields - 2.3 km/h in closed forests - 1.2 km/h in jungle - 0.025km/h if landmines Use dxdy to calculate the distance from nearest waypoint to the destination. Doing this last step in a separate function will have very little overhead costs. On Tue, Apr 19, 2016 at 8:39 PM, Steven M. Ottens <ste...@minst.net> wrote: > Hi all, > > I am working on a tool that will calculate the travel time from villages > to for instance the nearest hospital for rural accessibility analysis. So > far I have build a tool which will calculate this for 215.000 villages in a > few minutes, thanks to the help of Daniel P. However I realized that not > all villages are on a road, actually quite a few are at least an hour walk > from the nearest drivable road see: > http://stvno.github.io/img/OSRM-snapping.png > The villages are typically connected to the roads by informal trails, > which I do not have as a road network. So I was wondering if it would be > possible to add a basic penalty to the distance of the point to the nearest > road. > I am aware that the nearest service will provide me with the distance: > https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api#service-nearest > but before I am going to calculate the extra traveltime for each village, I > was wondering if it is possible to integrate this with an osrm.table > request. I am aware this opens quite a can of worms: if there is a penalty > to snapping, it might be worth it to snap to a road which is further away, > but in the end quicker to get to the destination. But for the moment I'm > happy with just the added traveltime for nearest road snapping. > > Any suggestions on how to handle this? > > Steven > > > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > -- Bjorn Madsen, Ph.D., MIET Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] routing with GPUs or mapD
That was a quick response...! :-) Thanks; Well - if anyone else is working on this - experimental or not - then please keep me posted as I'm interested in what you find. On Thu, Mar 31, 2016 at 11:06 PM, Daniel Patterson <dan...@mapbox.com> wrote: > Bjorn, > > This paper outlines one approach that is very fast: > > http://www.cs.princeton.edu/~rwerneck/papers/DKW14-crp-gpu.pdf > > and there are others: > > > https://pdfs.semanticscholar.org/0c17/805ab324006d40a8dd37d3550815824498fb.pdf > http://research.ijcaonline.org/volume72/number18/pxc3889386.pdf > http://public.lanl.gov/sunil/pubs/ipdps14.pdf > > The Contraction Heirachy approach that OSRM uses is not all that > amenable to GPU acceleration unfortunately. > > daniel > > On Mar 31, 2016, at 2:50 PM, Bjorn Madsen <b...@multiagenttechnology.com> > wrote: > > Brief introduction: > The difference between (1) routing + overlaying congestion data and (2) > routing with congestion data is that the former simply provides a route > which is extended with the delay given by the reduced travel speed inferred > from the congestion (option 1). We can do that easily today. > > Routing with congestion data (option 2) requires that the quickest path is > computed based on the congestion currently and the predicted congestion in > the near future. This results in completely different routes as the road > network velocity drops, whereby the fastest route (often) ends up being the > shortest, though junctions with accidents can generate minor detours. The > shift between the two modes of computation, is not linear, so walking the > graph is necessary in most cases. However as the walks could be performed > in concurrent lock-steps, it seems feasible to push such kind of workload > onto GPUs. > > Question: > I've been looking at mapD for a while and wondered whether it would be the > better alternative solution for routing that may include dynamic congestion > data into the routing process. Is anyone out there working with similar > thoughts - or, on using GPUs in the process? > > Kind regards > > -- > Bjorn Madsen > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[OSRM-talk] routing with GPUs or mapD
Brief introduction: The difference between (1) routing + overlaying congestion data and (2) routing with congestion data is that the former simply provides a route which is extended with the delay given by the reduced travel speed inferred from the congestion (option 1). We can do that easily today. Routing with congestion data (option 2) requires that the quickest path is computed based on the congestion currently and the predicted congestion in the near future. This results in completely different routes as the road network velocity drops, whereby the fastest route (often) ends up being the shortest, though junctions with accidents can generate minor detours. The shift between the two modes of computation, is not linear, so walking the graph is necessary in most cases. However as the walks could be performed in concurrent lock-steps, it seems feasible to push such kind of workload onto GPUs. Question: I've been looking at mapD for a while and wondered whether it would be the better alternative solution for routing that may include dynamic congestion data into the routing process. Is anyone out there working with similar thoughts - or, on using GPUs in the process? Kind regards -- Bjorn Madsen ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] osrm-extract taking hours to complete
Hi Kieran, I added a high speed SSD and pointed the .stxxl towards that to deal with the swap slowdown. That bought me a drop in processing time from 12 hrs -> 3-4 hrs. osrm@mat4:~/osrm-backend$ cat .stxxl *disk=/mnt/tmp/stxxl,40,syscall* osrm@mat4:~/osrm-backend$ lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 223.6G 0 disk ├─sda18:10 4G 0 part │ └─md0 9:00 4G 0 raid1 [SWAP] ├─sda28:20 512M 0 part │ └─md1 9:10 511.7M 0 raid1 /boot └─sda38:30 219.1G 0 part └─md2 9:20 219G 0 raid1 / sdb 8:16 0 223.6G 0 disk ├─sdb18:17 0 4G 0 part │ └─md0 9:00 4G 0 raid1 [SWAP] ├─sdb28:18 0 512M 0 part │ └─md1 9:10 511.7M 0 raid1 /boot └─sdb38:19 0 219.1G 0 part └─md2 9:20 219G 0 raid1 / *sdc 8:32 0 447.1G 0 disk * *└─sdc18:33 0 447.1G 0 part /mnt* On Wed, Mar 2, 2016 at 4:51 PM, Kieran Caplice <kieran.capl...@temetra.com> wrote: > Hello, > > I'm currently extracting the planet PBF (~31 GB), and it's been running > for hours. I notice in the "Running OSRM" wiki page, it says " On a Core i7 > with 8GB RAM and (slow) 5400 RPM Samsung SATA hard disks it took about 65 > minutes to do so from a PBF formatted planet", which is making me wonder > why it's taking so long on our server. Below are some example output > messages: > > [info] Parsing finished after 3584.35 seconds > [extractor] Erasing duplicate nodes ... ok, after 319.091s > [extractor] Sorting all nodes ... ok, after 3632.87s > [extractor] Building node id map ... ok, after 2025.29s > [extractor] Confirming/Writing used nodes ... ok, after 1096.24s > [extractor] Sorting edges by start... ok, after 2000.08s > > Some stxxl errors were outputted as I set the disk size to 100GB thinking > it was enough - but I didn't think it would cause such slowdowns as this, > considering extracting the Europe PBF takes hours also without the stxxl > errors. > > Server specs: > Ubuntu 14.04 > Intel Xeon CPU E5-1650 v3 @ 3.50GHz (hex-core with HT) > 64 GB RAM @ 2133 MHz > 2 TB Western Digital Enterprise 7200 RPM hard drive > > At the moment, disk IO is averaging around 35-40 MB/s R/W (~90%). > > Anyone have any ideas as to what might be going on? Or is it normal to > take this long without an SSD? > > Thanks in advance. > > Kind regards, > Kieran Caplice > > > _______ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] polyline usage?
Solved. Thanks..!
On Thu, Dec 17, 2015 at 5:23 PM, Sander Deryckere <sander...@gmail.com>
wrote:
> The algorithm is the same, but the precision in OSRM is higher, you should
> call the polyline function with a precision of 6 digits instead of 5.
>
> Regards,
> Sander
>
> 2015-12-17 18:14 GMT+01:00 Bjorn Madsen <b...@multiagenttechnology.com>:
>
>> Hi - I'm wondering what the better option is to get the polyline out as
>> list of latlons
>>
>> As example I'm using:
>>
>> waypoints = [(51.460982, -2.588994), (53.348429, -6.255323)]
>>
>>
>> which gives this long polyline http://pastebin.com/dhMZ2Nqb
>>
>> However, when I decode it, I get (the first 5 records only)
>>
>> = {tuple} (514.60953, -25.88957)
>> 0001 = {tuple} (514.61061, -25.88728)
>> 0002 = {tuple} (514.60382, -25.88428)
>> 0003 = {tuple} (514.59867, -25.88208)
>> 0004 = {tuple} (514.59651, -25.88124)
>>
>>
>> Any idea to what I'm doing wrong? Has the encoding changed from:
>> http://code.google.com/apis/maps/documentation/polylinealgorithm.html
>>
>>
>>
>>
>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
--
Bjorn Madsen
Director, Global Operations
Multi-Agent Technology Ltd.
Bessemer Drive,
Stevenage,
SG1 2DX
b...@multiagenttechnology.com
Mobile: +44 779 20 307 20
Main Office: +44 1438 310 035
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
[OSRM-talk] polyline usage?
Hi - I'm wondering what the better option is to get the polyline out as
list of latlons
As example I'm using:
waypoints = [(51.460982, -2.588994), (53.348429, -6.255323)]
which gives this long polyline http://pastebin.com/dhMZ2Nqb
However, when I decode it, I get (the first 5 records only)
= {tuple} (514.60953, -25.88957)
0001 = {tuple} (514.61061, -25.88728)
0002 = {tuple} (514.60382, -25.88428)
0003 = {tuple} (514.59867, -25.88208)
0004 = {tuple} (514.59651, -25.88124)
Any idea to what I'm doing wrong? Has the encoding changed from:
http://code.google.com/apis/maps/documentation/polylinealgorithm.html
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return
Hi - We're setting up a server to support the project with a modest 128 Gb RAM. Q1: What is the "right way" to get map updates for .pbf files? Any best practices out there? Nightly/Weekly builds? Do you get the data from http://download.geofabrik.de/ and are they okay with the traffic? Q2: What is the "right way" to prevent import of criminal map updates? I read on the OSM forum that somebody got banned after moving industry addresses around in updates, with a plausible suspicion on attempting to redirect deliveries (without payment). Q3: Any other best practices to keep in mind? Kind regards Bjorn On Tue, Nov 24, 2015 at 4:11 PM, Sander Deryckere <sander...@gmail.com> wrote: > > > 2015-11-24 16:07 GMT+01:00 Bjorn Madsen <b...@multiagenttechnology.com>: > >> Hi Sander & Emil, >> Thanks for the quick responses. The usage of the lua script is >> particularly useful. >> >> I completely respect the limitations of the demo server and can offer to >> set up another server to support the project. 20Tb of traffic should help? >> >> OSRM is open source, so you're completely free to install your own > server, to fit your own needs or anything you want. If you want to support > the community with an extra server, that would be great too. > > >> I've been following the discussions on the OSM forum and they've >> discussed the quality of the map to a great extend. >> For planning purposes I appreciate that the main source of error is delay >> in updates. To counter that we are planning to use our commercial help-desk >> to collect information from drivers about detours and unrecorded obstacles >> so that OSM can get the updates with less than a days delay. We can also >> track some vehicles, and capture information such as slowdown caused by >> traffic jams, etc. on major roads. Hopefully this can become a valued >> source of information? >> >> OSM only gathers permanent and verifiable information. And permanent > means that you can expect it to last at least one year after you mapped it. > Now, you can do some more temporary mapping (like setting a highway state > to "construction" if they're doing long works on it). But in general, > traffic jams, temporary obstacles etc don't belong in OSM. > > However, OSM is free to mix with other open data, so if anyone takes up > the job to create a database of temporary data, it can be combined with > OSM. Mapbox might indeed be interested in it, but I haven't seen any > successful and open databases like this so far. > > >> If somebody has a burning interest in accelerating this, then please feel >> free to get in touch for a sponsorship. >> That's the least I can do. >> >> Kind regards >> Bjorn >> >> <https://lists.openstreetmap.org/listinfo/osrm-talk> >> >> > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return
My name is Bjorn, and I'm the director at a commercial project that needs something like the Open Source Routing Machine with Openstreet Map where you both appear rather active. You can find a little bit about me on linkedin <https://uk.linkedin.com/in/bmadsen> and Multi-Agent Technology <http://www.multiagenttechnology.com/> London. *Question*: The most pressing question I have is whether OSRM is suitable for truck/lorry routing in its current state? I have no need to visualize the map data. Only calculation of the path, length and duration of the route for heavy goods vehicles for planning purposes. This means that I need to check for constraints such as weight, low bridges and width-limitations along the path. If queries are as quick as on the demo-server for the osrm-project, then time is on our side. In my lack insight, I imagine that this can be done in iterations, where first a path is chosen for cars, which subsequently is inspected for these constraints. If constraints are detected, alternatives will need to by discovered. I'm sure you have better ideas? I'm also on Google hangout (using this email) if you'd prefer to talk instead of writing longer emails. Thanks again for getting back to me. -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return
Hi Sander & Emil, Thanks for the quick responses. The usage of the lua script is particularly useful. I completely respect the limitations of the demo server and can offer to set up another server to support the project. 20Tb of traffic should help? I've been following the discussions on the OSM forum and they've discussed the quality of the map to a great extend. For planning purposes I appreciate that the main source of error is delay in updates. To counter that we are planning to use our commercial help-desk to collect information from drivers about detours and unrecorded obstacles so that OSM can get the updates with less than a days delay. We can also track some vehicles, and capture information such as slowdown caused by traffic jams, etc. on major roads. Hopefully this can become a valued source of information? If somebody has a burning interest in accelerating this, then please feel free to get in touch for a sponsorship. That's the least I can do. Kind regards Bjorn On Tue, Nov 24, 2015 at 2:51 PM, Sander Deryckere <sander...@gmail.com> wrote: > Hi, > > I'm writing this as an OSM mapper and user of the OSRM api, I'm not an > OSRM dev, so I might make some mistakes here. > > 2015-11-24 15:20 GMT+01:00 Bjorn Madsen <b...@multiagenttechnology.com>: > >> My name is Bjorn, and I'm the director at a commercial project that needs >> something like the Open Source Routing Machine with Openstreet Map where >> you both appear rather active. You can find a little bit about me on >> linkedin <https://uk.linkedin.com/in/bmadsen> and Multi-Agent Technology >> <http://www.multiagenttechnology.com/> London. >> >> *Question*: The most pressing question I have is whether OSRM is >> suitable for truck/lorry routing in its current state? >> > > The passability and driving speed of road types is determined by lua > scripts (see > https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua > for the example car script). So you can at least make one script per > vehicle type (split up your lorries in discrete types, and have a script > for every type). > > Now, OSRM is suited, but I don't know if OSM data is suited. Lorry tagging > is something not many mappers do (not many mappers need maxweight or > maxlength properties of a way), so data may be sparse. But this depends a > lot on the region you're operating in. It's generally known that Europe has > better coverage than North America, but even in Europe such tagging will > depend a lot on the region you're in. > >> >> I have no need to visualize the map data. Only calculation of the path, >> length and duration of the route for heavy goods vehicles for planning >> purposes. This means that I need to check for constraints such as weight, >> low bridges and width-limitations along the path. >> >> If queries are as quick as on the demo-server for the osrm-project, then >> time is on our side. In my lack insight, I imagine that this can be done in >> iterations, where first a path is chosen for cars, which subsequently is >> inspected for these constraints. If constraints are detected, alternatives >> will need to by discovered. I'm sure you have better ideas? >> >> The demo server is what it is, a demo. If you want truck routing, you'll > have to install your own server with your own profiles. > > >> I'm also on Google hangout (using this email) if you'd prefer to talk >> instead of writing longer emails. >> >> Thanks again for getting back to me. >> <https://lists.openstreetmap.org/listinfo/osrm-talk> > > > As for the return service you propose, if you use the data for truckers, > it would be great if you could get those truckers to help contribute data > to the database. In contrast to the average mapper, they will care about > maxweight and maxlength properties, and will want to correct those where > wrong. In turn, this also makes your data and your routes better. > > It can be achieved by giving the truckers a training on how to add that > data to OSM, or give them some option to add notes to OSM (in which case > these notes will have to be interpreted by regular mappers, and mapped). > > Regards, > Sander > > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return
Splendid. Do you know who to get in touch with from Mapbox? On Tue, Nov 24, 2015 at 3:15 PM, Emil Tin <z...@tmf.kk.dk> wrote: > Sounds great. > > > > Regarding GPS data, perhaps this is something Mapbox would be interested > in somehow processing. I think they’ve already worked on using GPS data to > adjust speed estimates in OSRM for cars. They’re also working on extending > OSRM so dynamic traffic data can be used to update the routing suggesting > in near real-time. > > > > > > Med venlig hilsen > > *Emil Tin* > IT- og Processpecialist > Trafik > ___ > KØBENHAVNS KOMMUNE > Teknik- og Miljøforvaltningen > Byens Anvendelse > > Njalsgade 13, 1035 > Postboks 380 > 2300 København S > > Direkte > > 2369 5986 > > Mobil > > 2369 5986 > > Email > > z...@tmf.kk.dk > > EAN > > 5798009493149 > > > > *Fra:* Bjorn Madsen [mailto:b...@multiagenttechnology.com] > *Sendt:* 24. november 2015 16:08 > *Til:* Mailing list to discuss Project OSRM > *Emne:* Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some > commercial support to you/ your projects in return > > > > Hi Sander & Emil, > > Thanks for the quick responses. The usage of the lua script is > particularly useful. > > > > I completely respect the limitations of the demo server and can offer to > set up another server to support the project. 20Tb of traffic should help? > > > > I've been following the discussions on the OSM forum and they've discussed > the quality of the map to a great extend. > > For planning purposes I appreciate that the main source of error is delay > in updates. To counter that we are planning to use our commercial help-desk > to collect information from drivers about detours and unrecorded obstacles > so that OSM can get the updates with less than a days delay. We can also > track some vehicles, and capture information such as slowdown caused by > traffic jams, etc. on major roads. Hopefully this can become a valued > source of information? > > > > If somebody has a burning interest in accelerating this, then please feel > free to get in touch for a sponsorship. > > That's the least I can do. > > > > Kind regards > > Bjorn > > > > > > On Tue, Nov 24, 2015 at 2:51 PM, Sander Deryckere <sander...@gmail.com> > wrote: > > Hi, > > I'm writing this as an OSM mapper and user of the OSRM api, I'm not an > OSRM dev, so I might make some mistakes here. > > > > 2015-11-24 15:20 GMT+01:00 Bjorn Madsen <b...@multiagenttechnology.com>: > > My name is Bjorn, and I'm the director at a commercial project that needs > something like the Open Source Routing Machine with Openstreet Map where > you both appear rather active. You can find a little bit about me on > linkedin <https://uk.linkedin.com/in/bmadsen> and Multi-Agent Technology > <http://www.multiagenttechnology.com/> London. > > > *Question*: The most pressing question I have is whether OSRM is suitable > for truck/lorry routing in its current state? > > > > The passability and driving speed of road types is determined by lua > scripts (see > https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua > for the example car script). So you can at least make one script per > vehicle type (split up your lorries in discrete types, and have a script > for every type). > > Now, OSRM is suited, but I don't know if OSM data is suited. Lorry tagging > is something not many mappers do (not many mappers need maxweight or > maxlength properties of a way), so data may be sparse. But this depends a > lot on the region you're operating in. It's generally known that Europe has > better coverage than North America, but even in Europe such tagging will > depend a lot on the region you're in. > > > > I have no need to visualize the map data. Only calculation of the path, > length and duration of the route for heavy goods vehicles for planning > purposes. This means that I need to check for constraints such as weight, > low bridges and width-limitations along the path. > > > > If queries are as quick as on the demo-server for the osrm-project, then > time is on our side. In my lack insight, I imagine that this can be done in > iterations, where first a path is chosen for cars, which subsequently is > inspected for these constraints. If constraints are detected, alternatives > will need to by discovered. I'm sure you have better ideas? > > > > The demo server is what it is, a demo. If you want truck routing, you'll > have to install your own server with your own profiles. > > > &g
Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return
Hi Florian, I presume that can assign vehicles to profiles and redirect the query based on a prepared dataset. How much space/ram would you anticipate per profile for all of EU? On Tue, Nov 24, 2015 at 3:36 PM, Florian Lohoff <f...@zz.de> wrote: > On Tue, Nov 24, 2015 at 02:20:16PM +0000, Bjorn Madsen wrote: > > > > I have no need to visualize the map data. Only calculation of the path, > > length and duration of the route for heavy goods vehicles for planning > > purposes. This means that I need to check for constraints such as weight, > > low bridges and width-limitations along the path. > > > > OSRM can do routing for Trucks. The problem might be that you seem > to want to calculate routing for dynamic height/weight etc. > > IMHO this might be difficult to achieve with OSRM. Basically with OSRM > you once prepare OSM data for usage with OSRM based on the type of > vehicle and its restrictions. So you would need to create different sets > for OSRM - Height e.g. 3.6m, 3.8m, 4m and e.g. weight 20to, 30to, 40to. > > There is no dynamic evaluation of the prepared graph. > > Flo > -- > Florian Lohoff f...@zz.de > We need to self-defend - GnuPG/PGP enable your email today! > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIVAwUBVlSD75DdQSDLCfIvAQoi9A/9FlBqCuULY1VQSIJbmskCVQ0vX6H2UgiD > 28yZagGWoeVWK5+0rXGUSCGSEIXkYFmDm0qxCfiIY1YNCTMfqqY4mEnpXAh8+L6i > 1sJuuANxH3tMjMb/l2q4DPF20IEuZx2dYiEVLuDP8f6vei1pF7XwrfiurtMIv+RP > O9wWkKuzy2TBpG7RLd0BfSFw2SWi4P0jfpj0mmLjqVYvOq1Cj8v/fwf6kIS4844b > TtJJfKTanKA2+wF8ipsiKpfupdhv5ltEfhbeNKq29oAgkXya2CBOREqNuXo/0S9S > CfYa3StX4Fa138MS14mf1Op9yDPJrOmnXOc+ELVoApf01ILByaliAzmaFNdl3sUH > WY2MQBQYlorGV6v6qIs9UpEiABpg1zOR16NKXDNWW4I1CVgpY9tMkL2Bz4fWHVza > pecnza/4dcFYwg3bhOPQSWFDGGz7wcIh5Kf6Jd8qUdJdW8RDGLQF7aUj/l3KkYci > C+qXQHuG4HGa5/m6t8bRsB5PNLMcgsOWfw0wZea5D7qwpaTHjt1cVJdPz/6735MH > HpiQ+pHEVZQq2IACRolPXmkizgrb233QJCeJrmjAnBDQFf9dkilmJhcx1rhw57Wp > 4ZTBInO8IuLsG1iLNIAhEFXgu/UB1zoOPsKijdKgKt0JCufZO1LWLua6SGpUuGyu > S5iP8rZ86ak= > =lr/t > -END PGP SIGNATURE- > > _______ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > > -- Bjorn Madsen Director, Global Operations Multi-Agent Technology Ltd. Bessemer Drive, Stevenage, SG1 2DX b...@multiagenttechnology.com Mobile: +44 779 20 307 20 Main Office: +44 1438 310 035 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
