Hi all,
Does anyone have any estimations on how long it would take to run assign_vertex_id on the entire Census TIGER dataset for the United States?
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has anybody done this and have a time and their computer's specs?
thanks
ian
On 6/1/2012 11:45 AM, Ian wrote:
Hi all,
Does anyone have any estimations on how long it would take to run
assign_vertex_id on the entire Census TIGER dataset for the United States?
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has
anybody done this and have a time and their computer's specs?
I'm going to take a wild guess that it is something in the ball park of 1 week. You have a secondary problem in that this is all done in a single stored procedure call, which means that it is all done in a single transaction. This might be an issue as the transaction will become extremely large.
You might look at using the TNIDF and TNIDT which are the Tiger assign node numbers.
So how are you planning on using this data with pgRouting? Tiger does not have attributes like oneway streets, zlevels at intersections or turn restrictions all of which are needed to do useful routing planning.
Are you aware the using tiger you will generate routes like enter an exit of highway, drive to the top of an overpas and make a left hand turn onto the underpass 20 feet below you, etc?
It can be useful for some restricted routing uses where you can overlook these issues but in general it is not suitable for most routing tasks.
-Steve
On 6/1/12 1:21 PM, Stephen Woodbridge wrote:
On 6/1/2012 11:45 AM, Ian wrote:
Hi all,
Does anyone have any estimations on how long it would take to run
assign_vertex_id on the entire Census TIGER dataset for the United States?
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has
anybody done this and have a time and their computer's specs?I'm going to take a wild guess that it is something in the ball park of 1 week. You have a secondary problem in that this is all done in a single stored procedure call, which means that it is all done in a single transaction. This might be an issue as the transaction will become extremely large.
You might look at using the TNIDF and TNIDT which are the Tiger assign node numbers.
So how are you planning on using this data with pgRouting? Tiger does not have attributes like oneway streets, zlevels at intersections or turn restrictions all of which are needed to do useful routing planning.
Are you aware the using tiger you will generate routes like enter an exit of highway, drive to the top of an overpas and make a left hand turn onto the underpass 20 feet below you, etc?
It can be useful for some restricted routing uses where you can overlook these issues but in general it is not suitable for most routing tasks.
-Steve
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
Thanks for the input.
So TNIDF & TNIDT can be imported to the 'source' & 'target' columns as long as they are properly linked to the endpoint geometry?
My project has to do with walking in cities so I'm thinking that I will be able to overlook routing issues associated with driving....I will have to make some assumptions though (sidewalks ped-xings), but streets in cities tend to be walkable.
I noticed that OSM data has some attribution TIGER data does not, maybe I should look there too.
Even if I clip the streets to only include the areas I really need (cities with a population of over 10,000), I'm guessing that would still be the majority of all the streets (maybe 1/3 or more?)
Well... if I end up doing assign_vertex_id on a large dataset I'll report back any useful results,
ian
On 6/1/2012 3:42 PM, Ian wrote:
On 6/1/12 1:21 PM, Stephen Woodbridge wrote:
On 6/1/2012 11:45 AM, Ian wrote:
Hi all,
Does anyone have any estimations on how long it would take to run
assign_vertex_id on the entire Census TIGER dataset for the United
States?
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has
anybody done this and have a time and their computer's specs?I'm going to take a wild guess that it is something in the ball park
of 1 week. You have a secondary problem in that this is all done in a
single stored procedure call, which means that it is all done in a
single transaction. This might be an issue as the transaction will
become extremely large.You might look at using the TNIDF and TNIDT which are the Tiger assign
node numbers.So how are you planning on using this data with pgRouting? Tiger does
not have attributes like oneway streets, zlevels at intersections or
turn restrictions all of which are needed to do useful routing planning.Are you aware the using tiger you will generate routes like enter an
exit of highway, drive to the top of an overpas and make a left hand
turn onto the underpass 20 feet below you, etc?It can be useful for some restricted routing uses where you can
overlook these issues but in general it is not suitable for most
routing tasks.-Steve
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-usersThanks for the input.
So TNIDF & TNIDT can be imported to the 'source' & 'target' columns as
long as they are properly linked to the endpoint geometry?My project has to do with walking in cities so I'm thinking that I will
be able to overlook routing issues associated with driving....I will
have to make some assumptions though (sidewalks ped-xings), but streets
in cities tend to be walkable.I noticed that OSM data has some attribution TIGER data does not, maybe
I should look there too.Even if I clip the streets to only include the areas I really need
(cities with a population of over 10,000), I'm guessing that would still
be the majority of all the streets (maybe 1/3 or more?)Well... if I end up doing assign_vertex_id on a large dataset I'll
report back any useful results,
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.
-Steve
Hi Ian,
If you decide to use OpenStreetMap data, osm2po (http://osm2po.de) 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.
I think the OSM community spend a lot of efforts after the Tiger data import to improve the road network with regard to routing.
Daniel
On Fri, Jun 1, 2012 at 10:25 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:
On 6/1/2012 3:42 PM, Ian wrote:
On 6/1/12 1:21 PM, Stephen Woodbridge wrote:
On 6/1/2012 11:45 AM, Ian wrote:
Hi all,
Does anyone have any estimations on how long it would take to run
assign_vertex_id on the entire Census TIGER dataset for the United
States?
Say you had a 2.6ghz intel core 2 duo processor and 8gb of RAM? Or has
anybody done this and have a time and their computer’s specs?I’m going to take a wild guess that it is something in the ball park
of 1 week. You have a secondary problem in that this is all done in a
single stored procedure call, which means that it is all done in a
single transaction. This might be an issue as the transaction will
become extremely large.You might look at using the TNIDF and TNIDT which are the Tiger assign
node numbers.So how are you planning on using this data with pgRouting? Tiger does
not have attributes like oneway streets, zlevels at intersections or
turn restrictions all of which are needed to do useful routing planning.Are you aware the using tiger you will generate routes like enter an
exit of highway, drive to the top of an overpas and make a left hand
turn onto the underpass 20 feet below you, etc?It can be useful for some restricted routing uses where you can
overlook these issues but in general it is not suitable for most
routing tasks.-Steve
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-usersThanks for the input.
So TNIDF & TNIDT can be imported to the ‘source’ & ‘target’ columns as
long as they are properly linked to the endpoint geometry?My project has to do with walking in cities so I’m thinking that I will
be able to overlook routing issues associated with driving…I will
have to make some assumptions though (sidewalks ped-xings), but streets
in cities tend to be walkable.I noticed that OSM data has some attribution TIGER data does not, maybe
I should look there too.Even if I clip the streets to only include the areas I really need
(cities with a population of over 10,000), I’m guessing that would still
be the majority of all the streets (maybe 1/3 or more?)Well… if I end up doing assign_vertex_id on a large dataset I’ll
report back any useful results,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.
-Steve
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de