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.
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@inwind.it
<mailto:paolo.lubrano@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.
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.
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).
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@inwind.it
<mailto:paolo.lubrano@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.
I’m approaching Navteq data in this days.
I have a navteq shapefile streets.shp, so the first thing to do (i suppose) is to import it in postgis with the shp2postgresql tool or with ogr2ogr library.
… 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).
you mean that I can directly use pgrouting on navteq data using ref_in_id and nref_in_id as source and target?
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@inwind.it
<mailto:paolo.lubrano@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.
On Jan 24, 2011, at 11:36 AM, lorenzo amato wrote:
Hi Charles, Hi list
I’m approaching Navteq data in this days.
I have a navteq shapefile streets.shp, so the first thing to do (i suppose) is to import it in postgis with the shp2postgresql tool or with ogr2ogr library.
If you need the Traffic table, be aware you will want to use the -n option instead of -I on that one since the latest navteq data does not contain any geometry in this table like it used to and it won’t load otherwise.
… 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).
you mean that I can directly use pgrouting on navteq data using ref_in_id and nref_in_id as source and target?
I said in theory It will probably need some preparation work, just like you’ll need to do some prep work for the assign_vertex way too. In the Navteq data each link has a ref_in_id and nref_in_id and a flag indicating the direction ‘dir_travel’, and any links that share these nodes meet. But many streets are bi-directional and the links are not all oriented from source to target (you have to use the combination of them to figure it out). So a street will be marked as going “from” the reference node ‘ref_in_id’ or “to” it (in other words “from” the non-reference node ‘nref_in_id’).
So you would likely want to first make sure all the links are aligned from source to target, and then possibly split out the bidirectional links into two links (one for each direction). I do both for my needs but I don’t think either are needed for the assign_vertex method (not sure on the bi-directional issue).
And as Stephen just said, I have seen several references to the fact that you want the source/target ids to be as small as possible for performance, so then you’d likely want to generate new source/target columns from them with incrementing numbers to get a smaller consecutive set.
Likewise feel free to use it, and it would be nice if it made it into pgRouting.