|
We intend to set up one or more dedicated OSM servers to manage almost exclusively drive time calculations. Using an offline solution, we manage 10-15 thousand drive time requests per machine per day (at constant 99% i7-CPU). Doing spot checks on Google, it handles easily several hundred requests a minute. But we do not know their system architecture and they limit to 1 Mio a year either way - we do those in a few weeks today (offline, local machines). Coverage should initially be Europe and North America. Better on two different machines? How will CPU and RAM influence the speed of complex drive time calculations? I've seen the info on mapping servers, but our focus is drive time calculation, not the mapping. |
|
OSRM will give the fastest results for your purposes, using the viaroute or matrix calls. In general, OSRM is limited by RAM rather than CPU. You will need at least a 64GB machine to create the routing data for North America or Europe, possibly even 128GB. However, once you are up and running, the requirements are less: North America and Western Europe will need around 10GB each. You may want to consider using cloud hosting (e.g. AWS or DigitalOcean) for the preprocessing, and then commodity hardware to run the server: I use my own hardware for the former and Hetzner servers for the latter. As long as the architectures and OSs are compatible (e.g. both Ubuntu on x86), you can move the routing files from one to another. OSRM has a demo public API which you can use to test whether it is suitable for your application. According to the message you used different OSRM versions. Try to use the same OSRM version as during the pre-processig step. Also please create a new question next time.
(26 Jan '17, 13:43)
scai ♦
The "next answer" is actually a comment on this one :) It can't be moved because of a bug in OSQA (because it's been edited I think).
(26 Jan '17, 14:09)
SomeoneElse ♦
1
Yes. I commented subbuj9's answer and then tried to move his "answer" to this answer. Due to the OSQA bug the answer can't be moved but the comment has been moved nevertheless :(
(26 Jan '17, 14:12)
scai ♦
@scai (as you've discovered now) you need to do that the other way around for it to work :)
(26 Jan '17, 14:25)
SomeoneElse ♦
|
|
Hi Richard, I used Azure cloud (Ubuntu 14, north america continental) for the pre-processing and successfully done. Moved files to local Ubuntu server. Getting below warning when i run the osrm-routed. Please help. [warn] .hsgr was prepared with different build. Reprocess to get rid of this warning. Ignoring the warning, do the requests actually work?
(26 Jan '17, 14:29)
Richard ♦
|
I guess it will be useful if you would mention which routing algorithm/library you are using.
I. Have. No. Idea :-D Okay, a basic draft one: http://www.yournavigation.org/ uses http://wiki.openstreetmap.org/wiki/YOURS and as Routing-Engine http://wiki.openstreetmap.org/wiki/Gosmore. We thought to try this first and then compare the results with the results from +20 engines (on- and offline, ie. Google, Bing, Apple, Maptitude, etc., etc.) we have on file (we used to "callibrate" our results) I thought if someone has experience with the hardware-requirements, there would be likely ideas what to use in such a scenario...? ツ
"I. Have. No. Idea" is also helpful. :-) If you do not yet know this wiki page... here it is: Routing. From what I've read in the past is that graphhopper and osrm are at least among the fastest ones. If you are looking for isochrones: OpenRouteService has such a feature. Other people here will be able to help you more, stand by.
Thanks! I/we saw the Routing page, but this is gibberish if you simply used existing, ready software. I also looked at https://lists.openstreetmap.org/listinfo/routing but our need is rather uncommon and there's contradictory information on solutions to use and they're all into single calculations, we talk about mass calculations. Common isochrones use simply drivetime on the minute, the "quick and dirty" solution that brings quick results but doesn't work. We need to associate statistical data, so we must go by fixed points that match given statistical administrative regions around the point of origin. That's my question. If you do MASS computations of drive times... What requirements should the server meet? What's the bottleneck? CPU, RAM? On our current tool, system runs at constant average of 99% CPU and we talk about reasonably current i7s Quad Core - of which we use effectively only two cores, adding a third or fourth only slows down the system... How is that in OSM. I do NOT know, if I'll get an answer, I do believe we pioneer something here... I just want to avoid running into an avoidable bottle neck when I buy new but the wrong hardware...