I am new to pgRouting and trying to figure out how to use it with navteq data. I used pgRouting with osm data and it worked perfect but for navteq data i tried to use ref_in_id and nref_in_id but it turned out that pgRouting found the path very slow when I used these for source and target. How can I calculate a correct topology for pgRouting by taking z levels into consideration ? Shall define geometry as 3D with z levels embedded or is it possible to use 2d multilinestring with additional z level column ?
Since I am new to pgRouting these questions are very hard for me to solve, but after I figure out how to use pgRouting I would be more than happy to contribute to project.
I’m not sure exactly about the ID’s of Navteq data. It’s too long ago that I have used it.
But it’s better to have ID’s starting with 1 and to keep them low. This might be the reason why it’s slow.
So you could create two new columns and renumber ID’s. You don’t have to run topology function.
I am new to pgRouting and trying to figure out how to use it with navteq data. I used pgRouting with osm data and it worked perfect but for navteq data i tried to use ref_in_id and nref_in_id but it turned out that pgRouting found the path very slow when I used these for source and target. How can I calculate a correct topology for pgRouting by taking z levels into consideration ? Shall define geometry as 3D with z levels embedded or is it possible to use 2d multilinestring with additional z level column ?
Since I am new to pgRouting these questions are very hard for me to solve, but after I figure out how to use pgRouting I would be more than happy to contribute to project.
I am using navteq data and would be happy to help, but I am about to take a week long vacation tomorrow morning so hopefully you are not in a rush.
The short answer is
assign_vertex does a good job of generating the source/target nodes using 0.00001 for me
for speed, I found I needed to limit the amount of data presented to the routing engine. One was is to reduce the data set (ie remove/limit the func_class 4 roads you don’t need). The other is I create a rectangle around the start and the end point and some percentage of the distance between the points as the width and limit the data to that. The narrower the rectangle the less data the routing engine uses, but if you have large arching roads you have to increase this (I use about 70%). Either way it helps speed up the routing for me.
For z levels search the archives but both Steven Woodbridge and I posted our versions of a 3d assign_vertex.
I’d be happy to answer any specific questions, and look forward to seeing your progress.
charles
On Jan 7, 2011, at 4:31 AM, Emre Koc wrote:
Hello,
I am new to pgRouting and trying to figure out how to use it with navteq data. I used pgRouting with osm data and it worked perfect but for navteq data i tried to use ref_in_id and nref_in_id but it turned out that pgRouting found the path very slow when I used these for source and target. How can I calculate a correct topology for pgRouting by taking z levels into consideration ? Shall define geometry as 3D with z levels embedded or is it possible to use 2d multilinestring with additional z level column ?
Since I am new to pgRouting these questions are very hard for me to solve, but after I figure out how to use pgRouting I would be more than happy to contribute to project.
I am using navteq data and would be happy to help, but I am about to take a week long vacation tomorrow morning so hopefully you are not in a rush.
The short answer is
assign_vertex does a good job of generating the source/target nodes using 0.00001 for me
for speed, I found I needed to limit the amount of data presented to the routing engine. One was is to reduce the data set (ie remove/limit the func_class 4 roads you don’t need). The other is I create a rectangle around the start and the end point and some percentage of the distance between the points as the width and limit the data to that. The narrower the rectangle the less data the routing engine uses, but if you have large arching roads you have to increase this (I use about 70%). Either way it helps speed up the routing for me.
For z levels search the archives but both Steven Woodbridge and I posted our versions of a 3d assign_vertex.
I’d be happy to answer any specific questions, and look forward to seeing your progress.
charles
On Jan 7, 2011, at 4:31 AM, Emre Koc wrote:
Hello,
I am new to pgRouting and trying to figure out how to use it with navteq data. I used pgRouting with osm data and it worked perfect but for navteq data i tried to use ref_in_id and nref_in_id but it turned out that pgRouting found the path very slow when I used these for source and target. How can I calculate a correct topology for pgRouting by taking z levels into consideration ? Shall define geometry as 3D with z levels embedded or is it possible to use 2d multilinestring with additional z level column ?
Since I am new to pgRouting these questions are very hard for me to solve, but after I figure out how to use pgRouting I would be more than happy to contribute to project.
I am also working on navteq data and it seems pretty straightforward to work with it. Just use assign vertex id 3d and it builds the network correctly.
I will also share my experiences with tsp and directions after I solve how to use them.
I am using navteq data and would be happy to help, but I am about to take a week long vacation tomorrow morning so hopefully you are not in a rush.
The short answer is
assign_vertex does a good job of generating the source/target nodes using 0.00001 for me
for speed, I found I needed to limit the amount of data presented to the routing engine. One was is to reduce the data set (ie remove/limit the func_class 4 roads you don’t need). The other is I create a rectangle around the start and the end point and some percentage of the distance between the points as the width and limit the data to that. The narrower the rectangle the less data the routing engine uses, but if you have large arching roads you have to increase this (I use about 70%). Either way it helps speed up the routing for me.
For z levels search the archives but both Steven Woodbridge and I posted our versions of a 3d assign_vertex.
I’d be happy to answer any specific questions, and look forward to seeing your progress.
charles
On Jan 7, 2011, at 4:31 AM, Emre Koc wrote:
Hello,
I am new to pgRouting and trying to figure out how to use it with navteq data. I used pgRouting with osm data and it worked perfect but for navteq data i tried to use ref_in_id and nref_in_id but it turned out that pgRouting found the path very slow when I used these for source and target. How can I calculate a correct topology for pgRouting by taking z levels into consideration ? Shall define geometry as 3D with z levels embedded or is it possible to use 2d multilinestring with additional z level column ?
Since I am new to pgRouting these questions are very hard for me to solve, but after I figure out how to use pgRouting I would be more than happy to contribute to project.
I'm also using Navteq data, it feels good to that I'm not alone with pgrouting and navteq since the documentation is about navteq + pgrouting is almost non-existent.
My colleagues and I are trying to figure how to update the rules for the shooting star algorithm to use driving restrictions. Any hints?
I'm also using Navteq data, it feels good to that I'm not alone with
pgrouting and navteq since the documentation is about navteq + pgrouting
is almost non-existent.
My colleagues and I are trying to figure how to update the rules for the
shooting star algorithm to use driving restrictions. Any hints?
Hi Henrik,
This is a problem area in my mind. Look in the list archive for "turn restrictions" I have posted about this in the past.
To summarize:
1. it is my opinion that we need to revamp how restrictions are defined in pgRouting and I have made some proposals, but we have not had any development resource that have had time to implement it
2. there some ability to enter turn restrictions when you add an edge if I recall. In theory, if you have multiple restrictions you have to add the edge multiple times one with each restriction. I haven't actually tried to do this so I'm not sure if or how well that works.
3. I'm not sure if you can add a complex restriction that requires multiple edges to define.
I’m also using Navteq data, it feels good to that I’m not alone with
pgrouting and navteq since the documentation is about navteq + pgrouting
is almost non-existent.
My colleagues and I are trying to figure how to update the rules for the
shooting star algorithm to use driving restrictions. Any hints?
Hi Henrik,
This is a problem area in my mind. Look in the list archive for “turn restrictions” I have posted about this in the past.
To summarize:
it is my opinion that we need to revamp how restrictions are defined in pgRouting and I have made some proposals, but we have not had any development resource that have had time to implement it
there some ability to enter turn restrictions when you add an edge if I recall. In theory, if you have multiple restrictions you have to add the edge multiple times one with each restriction. I haven’t actually tried to do this so I’m not sure if or how well that works.
I’m not sure if you can add a complex restriction that requires multiple edges to define.
Hope this helps,
-Steve
Hi Henrik and Steve,
About Navteq data:
It’s for sure one of the major network data sources … but it’s not available in Japan, where Anton and I (the ones, who wrote most of the documents) live and work. I think that’s the reason, why there isn’t more information available. We used Navteq sample data a bit out of interest, but didn’t spend very much time with it.
We would appreciate though if someone would volunteer to add some "How to use pgRouting with Navteq) information to the pgRouting website. The new website source files are in a Github repository: https://github.com/pgRouting/website. Anyone, who wants to add some content will get write access to it (Just send me your GitHub account username). The website is automatically updated from the repository every hour.
If this sounds too complicated, you can just write to the Wiki: https://github.com/pgRouting/website/wiki and I will then add it to the website.
About Shooting Star
I’m not sure if you can add a complex restriction that requires multiple edges to define.
You can define a list of ID’s to apply restrictions to multiple edges. As Steve mentioned, there might be other ways to implement this, but we’re a bit short on contributors (and of course on financial contribution
