Hi Ian,<div><br></div><div>If you decide to use OpenStreetMap data, osm2po (<a href="http://osm2po.de">http://osm2po.de</a>) can do very fast import of OSM data and it will output a PostgreSQL dump file you can use with pgRouting right away. On a fast server the import of a whole OSM planet file took just a few hours.</div>

<div>I think the OSM community spend a lot of efforts after the Tiger data import to improve the road network with regard to routing.</div><div><br></div><div>Daniel</div><div><br><br><div class="gmail_quote">On Fri, Jun 1, 2012 at 10:25 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 6/1/2012 3:42 PM, Ian wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/1/12 1:21 PM, Stephen Woodbridge wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/1/2012 11:45 AM, Ian wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Does anyone have any estimations on how long it would take to run<br>
assign_vertex_id on the entire Census TIGER dataset for the United<br>
States?<br>
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has<br>
anybody done this and have a time and their computer's specs?<br>
</blockquote>
<br>
I'm going to take a wild guess that it is something in the ball park<br>
of 1 week. You have a secondary problem in that this is all done in a<br>
single stored procedure call, which means that it is all done in a<br>
single transaction. This might be an issue as the transaction will<br>
become extremely large.<br>
<br>
You might look at using the TNIDF and TNIDT which are the Tiger assign<br>
node numbers.<br>
<br>
So how are you planning on using this data with pgRouting? Tiger does<br>
not have attributes like oneway streets, zlevels at intersections or<br>
turn restrictions all of which are needed to do useful routing planning.<br>
<br>
Are you aware the using tiger you will generate routes like enter an<br>
exit of highway, drive to the top of an overpas and make a left hand<br>
turn onto the underpass 20 feet below you, etc?<br>
<br>
It can be useful for some restricted routing uses where you can<br>
overlook these issues but in general it is not suitable for most<br>
routing tasks.<br>
<br>
-Steve<br>
______________________________<u></u>_________________<br>
Pgrouting-users mailing list<br>
<a href="mailto:Pgrouting-users@lists.osgeo.org" target="_blank">Pgrouting-users@lists.osgeo.<u></u>org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-users" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/pgrouting-<u></u>users</a><br>
</blockquote>
<br>
Thanks for the input.<br>
<br>
So TNIDF & TNIDT can be imported to the 'source' & 'target' columns as<br>
long as they are properly linked to the endpoint geometry?<br>
<br>
My project has to do with walking in cities so I'm thinking that I will<br>
be able to overlook routing issues associated with driving....I will<br>
have to make some assumptions though (sidewalks ped-xings), but streets<br>
in cities tend to be walkable.<br>
<br>
I noticed that OSM data has some attribution TIGER data does not, maybe<br>
I should look there too.<br>
<br>
Even if I clip the streets to only include the areas I really need<br>
(cities with a population of over 10,000), I'm guessing that would still<br>
be the majority of all the streets (maybe 1/3 or more?)<br>
<br>
Well... if I end up doing assign_vertex_id on a large dataset I'll<br>
report back any useful results,<br>
</blockquote>
<br></div></div>
You can probably just eliminate all the 1000, 1100 and probably the 1200 MTFCC class roads. The 1200 class roads you probably only want to eliminate them if the are divided (check the attributes). The routing methods prefer that nodes are mostly sequential (ie without big gaps in the number ranges) because of the way memory is allocated. So renumbering the TNIDx nodes might improve performance, but get it working fist then look ar performance issues.<div class="HOEnZb">

<div class="h5"><br>
<br>
-Steve<br>
______________________________<u></u>_________________<br>
Pgrouting-users mailing list<br>
<a href="mailto:Pgrouting-users@lists.osgeo.org" target="_blank">Pgrouting-users@lists.osgeo.<u></u>org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-users" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/pgrouting-<u></u>users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <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>