Hi Ben,<div><br></div><div>It's probably the ID being to large, yes.</div><div>osm2po generates an ID that also contains some information about the grid it belongs to, as far as I remember.</div><div><br></div><div>So if your total number of road links is OK and it would fir with integer, then it's better to renumber ID's, because it will also affect calculation speed. You can keep the ID that osm2po generated and just add a new column and renumber also source and target column accordingly.</div>
<div><br></div><div>Daniel</div><div><br></div><div><br><br><div class="gmail_quote">2010/12/12 Ben Brehmer <span dir="ltr"><<a href="mailto:ben@geooasis.com">ben@geooasis.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">As a follow up to my previous email, <div><br></div><div><br></div><div>I created a new routing table containing the edges that would have been considered in my previous query (on the entire USA). Then ran assign_vertix_id() to rebuild the source/target ids, and issued the same query with success. </div>
<div><br></div><div>This seems to indicate that the source, target and/or id fields are too large in my USA level routing table. This goes inline with this ticket, which has the same error I encountered on my previous 32 bit instance: <a href="http://download.osgeo.org/pgrouting/forum/pgrouting.postlbs.org/ticket/149.html" target="_blank">http://download.osgeo.org/pgrouting/forum/pgrouting.postlbs.org/ticket/149.html</a></div>
<div><br></div><div><br></div><div>Cheers,</div><div>Ben</div><div><div></div><div class="h5"><div><br><div><div>On 2010-12-11, at 9:54 PM, Ben Brehmer wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">
Hello,<div><br></div><div>Currently attempting to get PgRouting to work on a USA dataset. I have created the routing table (source, target, id, the_geom etc) with osm2po as all other routing converters (ie. osm2pgrouting) failed due to out of memory. Currently I am attempting to run a shortest_path_astar query. The result is a crashed Database and the following Postgres log: </div>
<div><br></div><div><div><i>terminate called after throwing an instance of '<b>std::bad_alloc</b>'</i></div><div><i> what(): <b>St9bad_alloc</b></i></div><div><i>LOG: server process (PID 1170) was terminated by signal 6: Aborted</i></div>
<div><i>LOG: terminating any other active server processes</i></div><div><i>FATAL: the database system is in recovery mode</i></div><div><i>LOG: all server processes terminated; reinitializing</i></div><div><i>LOG: database system was interrupted; last known up at 2010-12-12 05:17:42 UTC</i></div>
<div><i>LOG: database system was not properly shut down; automatic recovery in progress</i></div><div><i>LOG: <b>record with zero length at 1F/FCF370A8</b></i></div><div><i>LOG: redo is not required</i></div></div><div>
<br></div><div><br></div><div>I suspect my data may be the problem as it is all of USA (from Cloudmade OSM file). My max source/target ids are quite large:</div><div>Max source/target id: 25,638,274</div><div><br></div><div>
I have confirmed length and valid geometries on all rows in my sample query. I have confirmed valid source/target/ids on all rows in test query. </div><div><br></div><div>Without being a knowledgable C programmer, how would you suggest I go about debugging this? I have tried changing 'int' types in a_star.c to 'long' types, without luck. Without setting up an entire C development environment, is there a way to add debug statements to the C code (and then re-compile)? Tried increasing Postgres logging to the Maximum (debug5) and didn't receive any more useful information.</div>
<div><br></div><div><br></div><div>Any help is greatly appreciated! For more detailed system info, please read below.</div><div><br></div><div>Thanks!</div><div><br></div><div>Ben</div><div><br></div><div><br></div><div>
<br></div><div><br></div><div><br></div><div>Currently running on a 64 bit amazon (Large instance):</div><div><i>Linux version 2.6.34.7-56.40.amzn1.x86_64 (<a href="mailto:mockbuild@build-31005.build" target="_blank">mockbuild@build-31005.build</a>) (gcc version 4.4.4 20100525 (Red Hat 4.4.4-5) (GCC) ) #1 SMP Fri Oct 22 18:48:49 UTC 2010</i></div>
<div><br></div><div>Also tried the Amazon 32 bit Linux instance (Small instance type) and received a "<i>std::length_error, vector::_M_fill_insert</i>" error:</div><div><i>Linux version
2.6.34.7-56.40.amzn1.i686 (<a href="mailto:mockbuild@build-31003.build" target="_blank">mockbuild@build-31003.build</a>) (gcc version
4.4.4 20100525 (Red Hat 4.4.4-5) (GCC) ) #1 SMP Fri Oct 22 18:48:33 UTC
2010</i></div><div><br></div><div>Tried both Pgrouting 1.05 and 1.04. </div><div><br></div><div>I am running Postgres 8.4, PostGIS 1.5 as follows:</div><div><i>#select version();</i></div><div><div><i> version </i></div>
<div><i>------------------------------------------------------------------------------------------------------------------</i></div><div><i> PostgreSQL 8.4.5 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit</i></div>
</div><div><i><br></i></div><div><i>#select postgis_version();</i></div><div><div><i> postgis_version </i></div><div><i>---------------------------------------</i></div><div><i> 1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1</i></div>
</div><div><br></div><div>Sample Query:</div><div><br></div><div><div>SELECT * FROM shortest_path_astar(' </div><div> SELECT</div><div> roads.osm_id as id, roads.source::integer AS source, roads.target::integer AS target, (CASE WHEN roads.cost =0 THEN 1 ELSE roads.cost END)::float8 AS cost, roads.x1, roads.y1, roads.x2, roads.y2 </div>
<div> FROM </div><div> ways roads</div><div> WHERE </div>
<div> (the_geom && ST_Expand(ST_SetSRID(ST_MakeBox2d(ST_Point(-73.945798873896,40.644763731167), ST_Point(-73.955540657038,40.649745616898)),4326), 0.01) )</div>
<div> ', 42479854, 42497359, false, false) route ;</div></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></blockquote></div>
<br></div></div></div></div><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>