Hi Richard,<div><br></div><div>When you make a query you select your whole network table into memory ... which is huge, if it's all planet.osm road data.</div><div>To make this faster you should make a query, that only selects the road data you need. Why should you for example load North American roads, when you route in Europe.</div>
<div><br></div><div>As smaller the amount of selected data is, as faster you will get the result. That's the trick ;-) And if you route long distances you might want to consider to create a layered network and run multiple queries.</div>
<div>Look at the part with the bounding box wrapper. It applies for all algorithms, just look at Dijkstra chapter in the workshop: <a href="http://workshop.pgrouting.org/chapters/shortest_path.html#dijkstra">http://workshop.pgrouting.org/chapters/shortest_path.html#dijkstra</a></div>
<div><br></div><div>Daniel</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br><div class="gmail_quote">2011/1/14 Richard Marsden <span dir="ltr"><<a href="mailto:winwaed@gmail.com">winwaed@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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>
<font color="#888888">
<br><br>Richard Marsden<br><br>
</font><br>_______________________________________________<br>
Pgrouting-users mailing list<br>
<a href="mailto:Pgrouting-users@lists.osgeo.org">Pgrouting-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66, 99, 171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66, 99, 171)" target="_blank">http://georepublic.de</a></span><br>
</div>