[pgrouting-users] about use of navteq data

[Stephen Woodbridge]

On 1/24/2011 11:26 AM, Charles Galpin wrote:
> Sorry for not seeing this last week. Yes Stephen was kind enough to
> explain his algorithm to me when I ran into this and I implemented my
> own versions and posted them here as well (see the archives). They
> are different implementations of the same algorithm (credit goes to
> Stephen) so they should behave the same, but all I can tell you is
> mine "works for me" :)  Likewise feel free to use it, and it would be
> nice if it made it into pgRouting.

Lots of people contribute and we appreciate everyone's efforts.

> I have not tried it since I first started looking at pgRouting, but
> in theory you should be able to use navteq's ref_in_id and nref_in_id
> which are the equivalent of the source/target pgRouting builds
> itself, but I had issues (but can't recall the specifics).

The problem with using navteq's ref_in_id and nref_in_id is that you 
really need to renumber the nodes to start with number 1 because this 
impacts pgRouting performance and the amount of memory it needs if I 
remember correctly.

-Steve

> charles
>
> On Jan 21, 2011, at 11:09 AM, Stephen Woodbridge wrote:
>
>> He may have read that I did something like this. I hacked up a
>> version of assign_vertex where I stuffed the zlevel of the node
>> into the z value of the coordinated, so point(x, y, zlevel) and
>> then computed the distance_3d() or whatever the function is called
>> in postgis when comparing the vertices. This seems to work fine.
>>
>> I have attached my sql functions. Feel free to modify this and add
>> it to pgRouting as appropriate.
>>
>> -Steve
>>
>> On 1/21/2011 6:24 AM, Daniel Kastl wrote:
>>>
>>>
>>> 2011/1/21 Paolo Lubrano<paolo.lubrano at inwind.it
>>> <mailto:paolo.lubrano at inwind.it>>
>>>
>>> Hi all, hi Charles,
>>>
>>> actually I'm working on a pgrouting graph built on TeleAtlas
>>> Multinet data.
>>>
>>> I have problems with Z level, because two streets on different
>>> levels are considered as parts of crossroad.
>>>
>>> To explane better my problem this are the data of my network
>>> table:
>>>
>>>
>>> name                             source      target Tangenziale
>>> di Napoli    402837    413133 Via Giustiniano              402837
>>> 388759
>>>
>>>
>>> I built the graph with assign_vertex function, I have read about
>>> a new 3d version but I didn't found anything, where can I get
>>> it?
>>>
>>>
>>>
>>> You read this about PostGIS? pgRouting doesn't have a special
>>> support for 3D (Dijkstra algorithm even doesn't need geometry
>>> information). If you have two roads crossing each other sharing a
>>> node, but they actually shouldn't be connected, because they have
>>> different z-levels, then there shouldn't be shared node. Then the
>>> network topology isn't correct.
>>>
>>> If assign_vertex function produced this topology, then it would
>>> be good to think about how to identify such a case and add
>>> z-level support to assign_function. Maybe some extended
>>> assign_vertex function could check if the road segments are in
>>> the same z-level.
>>>
>>> Because you're using TeleAtlas data, are you sure you have to
>>> build a network topology? Doesn't TeleAtlas already contain such
>>> an information? If you need to run assign_vertex and your data is
>>> of good quality, you could make the "snapping" tolerance
>>> parameter very very slow. But this won't help if in your case
>>> both roads share exactly the same node.
>>>
>>> Daniel
>>>
>>>
>>>
>>>
>>> Thank you very much!
>>>
>>> Paolo
>
> _______________________________________________ Pgrouting-users
> mailing list Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users