Re: [OSRM-talk] Help - Off-line Routing

[Sayer, Bryan]

I'm not sure what your use case is.


We use the Stata implementation from S.Huber and C. Rust to do static routing. 
That is, we have a static list of starting points and ending points that we 
route in batch. You do have to build your routing maps first, and this takes a 
lot of memory, although this might depend on what area you are doing. We used 
the United States, and needed 64 GB to build the maps. Multiple threads are 
helpful for doing the routing.


I don't know about an interactive use in an off-line (air gaped) environment. 
But I also don't know why one would need an interactive use in such an 
environment.


The Stata program simply executes an operating system shell to run OSRM, so I 
imagine it would be very similar to something in C++.


https://www.uni-regensburg.de/wirtschaftswissenschaften/vwl-moeller/medien/huber/osrm_paper_online.pdf

osrmtime: Calculate Travel Time and Distance with OpenStreetMap Data Using the 
Open Source Routing Machine (OSRM) - 
uni-regensburg.de
www.uni-regensburg.de
2 osrmtime: Calculate Travel Time and Distance processor capable, and takes 
advantage of OSRM (Open Source Routing Machine)2. OSRM is a high-performance 
open-source C++ routing engine for shortest routes on




From: DigiMantra Technologies Ltd 
Sent: Friday, May 17, 2019 12:16:07 PM
To: osrm-talk@openstreetmap.org
Subject: [OSRM-talk] Help - Off-line Routing

Dear All,

 I have joined to this group recently. I have requirement for having off-line 
map routing for our VC++ based windows desktop application. I felt OSRM would 
be right fit for this requirement.

Have you used OSRM for similar projects? If so, can you please share us 
guidl-ines for implementing OSRM onto VC++ off-line applications ?

Thanks,
Karthik
Phone : +91 7418346873
DigiMantra Technologies Ltd,
Chennai,
India - 600100

WARNING This information may be confidential. It is intended only for 
the addressee(s) identified above. If you are not the addressee(s), or an 
employee or agent of the addressee(s), please note that any dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have received this information in error, please destroy the information and 
notify the sender of the error. Thank you.
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Swap file

[Sayer, Bryan]

My experience is probably with a slightly older version of OSRM, but I found 
that you have to have actual physical RAM (like 64G) to do the map extract. 
Creating a big swap space isn't sufficient. Some people advise doing the 
extract on an AWS cloud computer.


Bryan Sayer


From: "Thomas Rothenb?cher" 
Sent: Wednesday, February 13, 2019 9:55:47 AM
To: osrm-talk@openstreetmap.org
Subject: [OSRM-talk] Swap file

Hello everyone,

I would like to run osrm on my local machine on a 2.9G osm-file (namely 
Germany). As my machine does not have enough resources I would like to provide 
a swap file, which I did with:

(as root in root directory)

(mkdir /path/to/)
fallocate -l 10G /path/to/swapfile
chmod 600 /path/to/swapfile
mkswap /path/to/swapfile
swapon /path/to/swapfile

still after about 40 minutes into osrm-extract I got (full logs of 
osrm-extract):

./osrm-extract -p profiles/car.lua germany-latest.osm.pbf
[info] Parsed 0 location-dependent features with 0 GeoJSON polygons
[info] Using script profiles/car.lua
[info] Input file: germany-latest.osm.pbf
[info] Profile: car.lua
[info] Threads: 1
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2019-02-12T21:14:02Z
[info] Using profile api version 4
[info] Found 3 turn restriction tags:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parse relations ...
[info] Parse ways and nodes ...
[info] RAM: peak bytes used: 4516651008
[error] [exception] std::bad_alloc
[error] Please provide more memory or consider using a larger swapfile

As I was monitoring my memory usage over top I could see that there was a lot 
of swap space left.


My .stxxl-file (located inside the folder where I executed osrm-extract):

disk=/path/to/swapfile,9000,syscall



I'm running Ubuntu 18.04 (in a VM) with 5GB of RAM and a Disk of 30 GB.

So I probably missed something somewhere.
Would would you recommend? Can I even hope to use libosrm on germany with these 
resources?

Any assistence is greater appreciated.

Thank you!





WARNING This information may be confidential. It is intended only for 
the addressee(s) identified above. If you are not the addressee(s), or an 
employee or agent of the addressee(s), please note that any dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have received this information in error, please destroy the information and 
notify the sender of the error. Thank you.
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Updating a map

[Sayer, Bryan]

It is possible that your problem is something other than memory, but I have no 
way of knowing.


I believe the usual advice is to use a service like Amazon Web Service (AWS) 
where you can use a machine with more memory for the amount of time it takes to 
prepare the maps. I imagine it would be pretty reasonable in price.


From: Didier Doumerc 
Sent: Friday, August 10, 2018 3:34:42 AM
To: Mailing list to discuss Project OSRM
Subject: Re: [OSRM-talk] Updating a map

I have only 12 GB of RAM but when I installed the previous file version, it was 
ok with only 4 GB or RAM.

Is there anyway way to successfully prepare the files ? Perhaps by downloading 
them ready yet ?

Thanks for your answer.

Didier

Le jeu.09/08/18 à 18:15, Sayer, Bryan a écrit :

When I had that problem it was due to lack of memory. For the United States, I 
had to have 64 GB of memory prepare, though I was doing it through a Stata 
interface, not directly.

From: Didier Doumerc mailto:doumer...@adimep.com>>
Sent: Thursday, August 9, 2018 11:53:39 AM
To: osrm-talk@openstreetmap.org<mailto:osrm-talk@openstreetmap.org>
Subject: [OSRM-talk] Updating a map

Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%

[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . [flush 
9336408 nodes]  70% . 80% . 90% .



Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 relations, 
and 0 unknown entities
[extractor] Sorting used nodes... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes ... ok, after 270.95s
[extractor] Building node id map  ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start... ok, after 46.7546s
[extractor] Setting start coords  ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes   ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]  

Re: [OSRM-talk] Updating a map

[Sayer, Bryan]

When I had that problem it was due to lack of memory. For the United States, I 
had to have 64 GB of memory prepare, though I was doing it through a Stata 
interface, not directly.


From: Didier Doumerc 
Sent: Thursday, August 9, 2018 11:53:39 AM
To: osrm-talk@openstreetmap.org
Subject: [OSRM-talk] Updating a map

Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%

[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . [flush 
9336408 nodes]  70% . 80% . 90% .



Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 relations, 
and 0 unknown entities
[extractor] Sorting used nodes... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes ... ok, after 270.95s
[extractor] Building node id map  ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start... ok, after 46.7546s
[extractor] Setting start coords  ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes   ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 turns, defined by 31859 restrictions
[info]   skips 11264858 U turns
[info]   skips 18504 turns over barriers
[info] Timing statistics for edge-expanded graph:
[info] Renumbering edges: 0.239598s
[info] Generating nodes: 10.5262s
[info] Generating edges: 44.5756s
[info] building r-tree ...
[info] large component [6711]=13836854
[info] SCC run took: 1.89227s
[info] constructing r-tree of 37961020 edge elements build on-top of 36442184 
coordinates
[info] finished r-tree construction in 23.796 seconds
[info] writing node map ...
[extractor] Writing edge-based-graph egdes   ... ok, after 3.98042s
[info] Processed 25874228 edges
[info] Expansion  : 274152 nodes/sec and 104966 edges/sec
[info] To prepare the data for routing, run: ./osrm-prepare france-latest.osrm

[STXXL-ERRMSG] Removing disk file: /var/tmp/stxxl
logout
Saving session...

Re: [OSRM-talk] calculation of jump distances

[Sayer, Bryan]

Thanks! I was wondering if some of these might be islands. I haven’t had time 
to check out the details of ones with extra large jump distances yet, but I’ll 
try to do that in the next few days.

Bryan Sayer
(301) 628-1576

From: Daniel Patterson [mailto:dan...@mapbox.com]
Sent: Thursday, January 18, 2018 12:25 PM
To: Sayer, Bryan <bsa...@s-3.com>
Cc: Mailing list to discuss Project OSRM <osrm-talk@openstreetmap.org>
Subject: Re: [OSRM-talk] calculation of jump distances

Hi Bryan,

  OSRM uses an R-Tree (https://en.wikipedia.org/wiki/R-tree) to do a nearest 
neighbour search (https://en.wikipedia.org/wiki/Nearest_neighbor_search).  
Every segment (line between two OSM nodes) is indexed in the R-Tree, and we 
snap to the closest straight line, measured with the Haversine distance method.

  One thing that might be coming into play is OSRM's "small component" snapping 
behaviour - how OSRM behaves when your start and end point are not actually 
connected (e.g. one point on an island, one on the mainland).

  There's an older blog post here:


https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8

  that describes this behaviour.  It's possible this is coming into play for 
some locations, but you'd need to look very closely at your data and the 
failing requests to really understand what's going on.

daniel

On Wed, Jan 17, 2018 at 7:10 AM, Sayer, Bryan 
<bsa...@s-3.com<mailto:bsa...@s-3.com>> wrote:
Hi Daniel,

Thanks for the advice. We use the Stata implementation on a secure network so I 
can’t try any of the usual options that are available over the internet. I will 
double check that I have the order (longitude, latitude) but I have over 450 
million routes all over the USA (every populated tract to every hospital, with 
certain restrictions in Hawaii and Alaska), so I imagine if I had them reversed 
I would have really strange results.

I can check the area size of the tracts. I suppose some tracts might not have 
any roads, but generally tracts are defined by roads or natural elements like 
rivers. I only use tracts with non-zero population, so it seems like every 
tract I use should have a road in it. It seems to me that it should never be 
the case that the jump distance from the tract centroid to the starting point 
should exceed the largest dimension of the tract, or really one-half of that 
distance.

It is not a large number of routes with these large jump distances, just a few.

When you say “the first thing that happens is that the nearest point on the 
road network is found” how is the nearest road network found? That is, what is 
the algorithm? Does it spiral out from the point until a road is hit?


Bryan Sayer
Statistician
Social & Scientific Systems, Inc.
Monday-Friday 9:30 to 5:30
(301) 628-1576<tel:(301)%20628-1576>
https://www.s-3.com/


From: Daniel Patterson [mailto:dan...@mapbox.com<mailto:dan...@mapbox.com>]
Sent: Tuesday, January 16, 2018 5:24 PM
To: Mailing list to discuss Project OSRM 
<osrm-talk@openstreetmap.org<mailto:osrm-talk@openstreetmap.org>>
Subject: Re: [OSRM-talk] calculation of jump distances

Hi Bryan,

  OSRM stores the road network in memory.  When you supply a coordinate to 
start/finish a route, the first thing that happens is that the nearest point on 
the road network is found.  Routing then happens from those "snapped" points.

  If you've got big rural areas, and you're using large regional centroids, 
then I suspect the snapping is starting or finishing your routes on roads you 
don't expect.

  Several hundred KM is pretty weird though, unless your road network is 
*really* sparse.  Do you have your coordinate the correct way around in your 
requests?  The order should be , for every pair - getting 
this wrong is often the source of really weird results.

  Try making a single request with `overview=full=geojson`, then 
plot the full route geometry on http://geojson.io/ or something to see if it 
even looks reasonable.

daniel

On Tue, Jan 16, 2018 at 1:43 PM, Sayer, Bryan 
<bsa...@s-3.com<mailto:bsa...@s-3.com>> wrote:

Hi,



We are calculating distances between an U.S. census tract centroid and 
hospitals. A tract averages about 4,000 people, but can vary in area. 
Obviously, the centroid is likely to not be on a street, and thus a jump 
distance has to be calculated to get to a street.



Our question is what is the general algorithm for getting to the starting 
point? We definitely end up with some very large numbers (several hundred 
kilometers) on some jump distances, which seems incorrect.



Bryan Sayer

WARNING This information may be confidential. It is intended only for 
the addressee(s) identified above. If you are not the addressee(s), or an 
employee or agent of the addressee(s), please note that any dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have recei

[OSRM-talk] calculation of jump distances

[Sayer, Bryan]

Hi,


We are calculating distances between an U.S. census tract centroid and 
hospitals. A tract averages about 4,000 people, but can vary in area. 
Obviously, the centroid is likely to not be on a street, and thus a jump 
distance has to be calculated to get to a street.


Our question is what is the general algorithm for getting to the starting 
point? We definitely end up with some very large numbers (several hundred 
kilometers) on some jump distances, which seems incorrect.


Bryan Sayer

WARNING This information may be confidential. It is intended only for 
the addressee(s) identified above. If you are not the addressee(s), or an 
employee or agent of the addressee(s), please note that any dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have received this information in error, please destroy the information and 
notify the sender of the error. Thank you.
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Sayer, Bryan]

Just as a point of reference, you mention that avoiding swapping and just using 
RAM will be much faster. If the swap space is an SSD drive, how much does using 
only RAM speed up contract? That is, what is the difference between using say a 
7200 rpm SATA drive versus an SSD drive make?


From: Daniel Patterson 
Sent: Friday, September 22, 2017 8:05:56 AM
To: Mailing list to discuss Project OSRM
Subject: Re: [OSRM-talk] Expecting time for osrm-contract for planet

Hi Kieran,

  We don't, but I've done some profiling in the past, Docker itself should have 
negligible impact.

  The two things that might be slowing things down:

1) The docker images don't bundle jemalloc (http://jemalloc.net/), which 
can speed things up by 10-15%
2) osrm-contract is very CPU intensive - the more threads you give it, the 
faster it will run.  Give it more if you can.

 256GB of RAM should be more than enough to avoid swapping, but you might want 
to disable swap to be sure - if it's being used, it will have a huge impact on 
speed.

daniel

On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice 
> wrote:

Hi Daniel,

Can you clarify if you use Docker at Mapbox? What kind of server do you guys 
have (if not the one described on the wiki page)?

Over night, the process has gone to just 75% complete from 65% yesterday - 41 
hours in total now, and back to maxing CPU again.

Kind regards,
Kieran Caplice

On 21/09/17 17:17, Daniel Patterson wrote:
OSRM supports *two* core routing algorithms - CH and MLD.  The `osrm-contract` 
tool generates the CH dataset, but you can use the MLD pipeline instead with:

osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
osrm-partition yourmap.osrm
osrm-customize yourmap.osrm
osrm-routed -a MLD yourmap.osrm

This sequence of tools should be significantly quicker than osrm-contract - the 
price you pay is that routing requests are about 5x slower (still pretty fast 
though!).  The reason that MLD exists is for the `osrm-customize` step - it 
allows you to import traffic data very quickly and update the routing graph (~1 
minute for North America).

It's hard to say exactly what's going wrong with osrm-contract here - here at 
Mapbox, we daily run `osrm-contract` over the latest planet with the bicycle 
profile without a problem, however, Alex and others have reported issues with 
what seem like hangs on much smaller datasets that we've been unable to 
reproduce so far.

The runtime of osrm-contract is affected by how much hierarchy exists in the 
data - the more similar the edge speeds (like in foot) and the more edges there 
are, the slower it gets, often in a non-linear fashion.  The car profile has a 
very hierarchical structure (many different road speeds), so it fits well into 
the CH, the construction algorithm  doesn't need to compare as many options.

daniel

On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice 
> wrote:

We're actually looking for the best of both car and foot, so in my head, 
bicycle would be the happy medium (though I could be completely wrong on this).

Kind regards,
Kieran Caplice

On 21/09/17 16:53, Alex Farioletti wrote:
i've run into the same issues, and now i just use metroextracts of the areas 
that i need for the bike stuff i do and it reduces the time significantly

Alex Farioletti
415.312.1674
tcbcourier.com

On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice 
> wrote:

Thanks Daniel.

I'm using the bicycle profile, so I would expect based on what you've said that 
somewhere up to 36 hours would be likely. However, this is the current output, 
after 25h40m:

[info] Input file: /data/1505492056/planet-latest.osrm
[info] Threads: 12
[info] Reading node weights.
[info] Done reading node weights.
[info] Loading edge-expanded graph representation
[info] merged 2379332 edges out of 152432
[info] initializing node priorities... ok.
[info] preprocessing 389797971 (90%) nodes...
[info] . 10% . 20% . 30% . 40% . 50% . 60%

It hasn't advanced past 60% in the last 2-3 hours. It is however maxing CPU and 
using approximately the same amount of RAM since it started.

Kind regards,
Kieran Caplice

On 21/09/17 16:39, Daniel Patterson wrote:
Hi Kieran,

  The contraction time will be slow - many, many hours for the whole planet.  
*Typically* for the car profile it's about 12 hours, but if you use bike or 
foot, or your own profile, it can get a lot bigger.

  If you've messed with the travel speeds, that can have a big effect too.  24 
hours is not unheard of, but whether it's legit will depend a lot on the 
details.

daniel

On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice 
> wrote:
Hi all,

Could anyone give an approx estimate for the time required to run the