Well I'm back to trying to get pgRouting working again with my planet.osm file. This has been loaded into Postgres with Osm2po.<br><br>I'm not sure if I've got the right parameters, but pretty much every variation I try results in long running (tens of minutes) before it crashes with an out of memory error (typically around 39017600).<br>
<br>An example query:<br><br>SELECT * FROM shortest_path (<br>'SELECT id, source, target, cost, reverse_cost FROM osm_topo' , 44070476, 44070478, true, true );<br><br>I've also tried a few different functions other than shortest_path(). The node numbers were picked from a query of the first few rows. I also checked indexes: osm2po produced indexes on source, target, etc.<br>
<br>It seems that the inner query which is passed as a parameter to shortest_path (or any of the other functions) might be querying the entire dataset? Which of course is huge as I've got the entire OSM planet file loaded into PostGres. So I tried adding a WHERE clause to the inner SELECT that only queries x1,y1 coordinates within a range (x1,y1 for Node 44070476 is about 55,51, so I chose 50.0->60.0 and 45.0->56.0 as my ranges).<br>
<br>No better.<br><br>So I think I'm really pushing the limits. planet.osm is of course huge, and despite the significant pruning by osm2po the resulting routing network is still very large. I guess pgRouting just doesn't scale to such admittedly large datasets.<br>
(I note that the online OpenLayers-based demos are limited to individual cities)<br><br>I wish to eventually do my bulk routing on a country-by-country basis, but it would not be practical to load each country individually. I'll look to see if there are any other approaches, perhaps with a different offline routing engine (using a web service is not deemed practical), but it looks like this project is probably going to be dead in the water.<br>
<br><br>Richard Marsden<br><br>