[pgrouting-users] Question about driving_distance calculation

pgRouting pgrouting-users
1

Hi all,

I need some information about driving_distance calculation function:

1) the query point(source_id) has to be a vertex or can it be a 2D point that is mapped to the closest possible edge?
2) what happens with edges, that are partially reached? (one vertex is reached in time, the other one is not)
3) is the entire network loaded into main memory for doing such a computation?

thanks for your answer

best regards

Markus Innerebner

2

2011/1/11 Markus Innerebner <markus.innerebner@inf.unibz.it>

Hi all,

I need some information about driving_distance calculation function:

  1. the query point(source_id) has to be a vertex or can it be a 2D point that is mapped to the closest possible edge?

Driving Distance functions starts with a vertex. (There is a wrapper function that takes coordinates as start and searches for the nearest vertex from the given point).

  1. what happens with edges, that are partially reached? (one vertex is reached in time, the other one is not)

Driving Distance only cares about vertices, because it works like Dijkstra algorithm. You can take the vertices and write an SQL function for example, that returns you the edges … or a polygon.

  1. is the entire network loaded into main memory for doing such a computation?

This depends on your query. You can only select the network in your query that you think is relevant for your result. Usually you select a bounding box around your start point. It’s easy to guess how large this area is, if you cost parameter is a distance. It’s more difficult if you cost parameter is time for example. If your bounding box was too small, then your result might have the shape of a square.

Daniel

thanks for your answer

best regards

Markus Innerebner

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

3

Hello Daniel

thanks for your detailed answers.

Driving Distance functions starts with a vertex. (There is a wrapper
function that takes coordinates as start and searches for the nearest vertex
from the given point).

2) what happens with edges, that are partially reached? (one vertex is
reached in time, the other one is not)

Driving Distance only cares about vertices, because it works like Dijkstra
algorithm. You can take the vertices and write an SQL function for example,
that returns you the edges ... or a polygon.

ok, thanks

The algorithm uses only the cost column(or reverse_cost column) of the edges to compute the costs of the target vertex? This means there is no way to compute the cost in dependency of a passed walking speed parameter, where cost are defined as edge_length/speed.

regards

Markus

4

ok, thanks

The algorithm uses only the cost column(or reverse_cost column) of the edges to compute the costs of the target vertex? This means there is no way to compute the cost in dependency of a passed walking speed parameter, where cost are defined as edge_length/speed.

The cost is what you define as cost. Anything is OK. You select the cost column in your query, which can be a combination of several attributes.

Daniel

regards

Markus

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

5

On 1/11/2011 11:34 AM, Markus Innerebner wrote:

Hello Daniel

thanks for your detailed answers.

Driving Distance functions starts with a vertex. (There is a wrapper
function that takes coordinates as start and searches for the nearest
vertex
from the given point).

2) what happens with edges, that are partially reached? (one vertex is
reached in time, the other one is not)

Driving Distance only cares about vertices, because it works like
Dijkstra
algorithm. You can take the vertices and write an SQL function for
example,
that returns you the edges ... or a polygon.

ok, thanks

The algorithm uses only the cost column(or reverse_cost column) of the
edges to compute the costs of the target vertex? This means there is no
way to compute the cost in dependency of a passed walking speed
parameter, where cost are defined as edge_length/speed.

You might be able to define a view where you add a column walking_speed and compute the value you want.

Then pass the view to the wrapper along with your new column name.

Also I would recommend reading the plpgsql of the wrapper function. It should be pretty easy to clone it and modify it to meet you needs. I have done this for some of my projects.

-Steve W

6

Daniel Kastl wrote:

ok, thanks

The algorithm uses only the cost column(or reverse_cost column) of the
edges to compute the costs of the target vertex? This means there is no way
to compute the cost in dependency of a passed walking speed parameter, where
cost are defined as edge_length/speed.

The cost is what you define as cost. Anything is OK. You select the cost
column in your query, which can be a combination of several attributes.

ok, perfect.

My last question now:
the function returns a edge_id, described by the identifier of the edge crossed. What is the benefit of this attribute? What does this edge do?
If the result contains the vertices reached in the given time from the query point, why also adding the edge identifier?

Markus

7

2011/1/12 Markus Innerebner <markus.innerebner@inf.unibz.it>

Daniel Kastl wrote:

ok, thanks

The algorithm uses only the cost column(or reverse_cost column) of the
edges to compute the costs of the target vertex? This means there is no way
to compute the cost in dependency of a passed walking speed parameter, where
cost are defined as edge_length/speed.

The cost is what you define as cost. Anything is OK. You select the cost
column in your query, which can be a combination of several attributes.

ok, perfect.

My last question now:
the function returns a edge_id, described by the identifier of the edge crossed. What is the benefit of this attribute? What does this edge do?
If the result contains the vertices reached in the given time from the query point, why also adding the edge identifier?

Nothing :wink: … it doesn’t do anything as far as I remember. (or please correct me, Anton)
It’s possible to discuss whether this is a good idea or not, but the reason is that the query result is in the same form as the core shortest path functions. You don’t need to select everything (“*”).

Daniel

Markus

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