[pgrouting-users] Assign Vertex ID time

[Daniel Kastl]

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 at 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 at lists.osgeo.**org <Pgrouting-users at lists.osgeo.org>
>>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-**users<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,
>>
>
> 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 at lists.osgeo.**org <Pgrouting-users at lists.osgeo.org>
> http://lists.osgeo.org/**mailman/listinfo/pgrouting-**users<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>
>



-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20120602/15d1fc76/attachment.html>