Is osm2pgrouting 2.1 compatible with pgr_dijkstra?

[lab348]

In version 2.0 of osm2pgrouting length was not calculated in m, but rather in degrees, so I used this query to fix this:
UPDATE public.ways
SET
length= ST_Length(the_geom::geography),
reverse_cost= CASE WHEN length>=reverse_cost THEN ST_Length(the_geom::geography) ELSE ST_Length(the_geom::geography)_1000000 END,
to_cost= CASE WHEN length<=reverse_cost THEN ST_Length(the_geom::geography) ELSE ST_Length(the_geom::geography)_1000000 END;

In version 2.1 I see that there already is length_m, so I could use it, but I am concerned about reverse_cost. It is still in degrees and negative numbers rather than *1000000 are used for one way streets. Will pgr_dijkstra be compatible with such values or should I run above query?

[cvvergara]

Hello,
in pgRouting version 2.0 pgr_dijsktra (and the rest of the functions) did not read the correct values:
"a negative value the edge is not inserted" because of that, that query was necessary.
but you might still need to use that query for the not yet fixed functions like Astar, bd_dijkstra,

[lab348]

My pgRouting version is 2.0.0-3. I am not sure if I understand you well. You mean that in this version of pgrouting negative values were not properly handled? As I would like to use osm2pgrouting 2.1, should I switch to pgRouting 2.2? Still I am not sure which columns to use with pgr_dijsktra if I would like to find ways using real distance. As a cost length_m seems to be ready, but what about reverse cost?

[cvvergara]

" one_way"
-1 reversed (1 way but geometry is reversed)
0 unknown,
1 yes(normal direction),
2 not one way its 2 way,
3 reversible (one way street but direction changes depending the time of the day)

This is what osm2pgrouting does to cost column and reverse_cost column
0 & 2 & 3 put positive values on all cost /reverse_cost
-1 has negative value on cost column
1 has negative value on reverse_cost column

[lab348]

Sorry, but I am still confused. Your description is ok and I understand it. However, this does not answer my questions, which are:

1. Will pgRouting 2.0 work properly with data imported by osm2pgrouting 2.1, or shoud I switch to pgRouting 2.2?
2. What should I do, If I would like to have routing based on real distance? Recalc cost and reverse_cost using algorithm described by you? Why in fact cost and reverse_cost is not expressed in meters? Degrees are rather useless, because they don't give real length.

[cvvergara]

dijkstra in v2.0 has bugs.

On Tue, Apr 19, 2016 at 2:04 PM, lab348 notifications@github.com wrote:

Sorry, but I am still confused. Your description is ok and I understand
it. However, this does not answer my questions, which are:

1. Will pgRouting 2.0 work properly with data imported by osm2pgrouting
   2.1, or shoud I switch to pgRouting 2.2?
2. What should I do, If I would like to have routing based on real
   distance? Recalc cost and reverse_cost using algorithm described by you?
   Why in fact cost and reverse_cost is not expressed in meters? Degrees are
   rather useless, because they don't give real length.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#129 (comment)

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl

[lab348]

Ok, so I will switch to v2.2.
Will this query be fine to fix cost and reverse_cost to length in m?
UPDATE public.ways
SET
reverse_cost= CASE WHEN reverse_cost>=0 THEN length_m ELSE -length_m END,
cost= CASE WHEN cost>=0 THEN length_m ELSE -length_m END;

[cvvergara]

yes.