postgresql - How to get correct pgRouting results -


i trying pgrouting based on osm data run , have problems in getting right.

i installed postgresql 9.5 on ubuntu machine. postgis_full_version comes with

  • "postgis="2.2.2 r14797"
  • geos="3.4.2-capi-1.8.2 r3921"
  • proj="rel. 4.8.0, 6 march 2012"
  • gdal="gdal 1.11.2, released 2015/02/10"
  • libxml="2.9.1"
  • libjson="0.11.99"
  • topology raster",

and pgrouting in version 2.2.3 installed.

i using osm2pgrouting in version 2.1 import osm file geofabrik , build topology.

after importing, column 'length' in table ways holds small values, while supposed have distance information in kilometres. comparison column 'length_m' shows either distance in meter or 1 in kilometres wrong. based on discussion can fix distance issue.

however, column 'cost' seems copy of column 'length' , in discussion linked above cost column isn't recalculated, , not sure if should done well.

hence added column ('to_cost') recalculated distances. following sql query makes use of this:

select sum(distance) "distance (km)", sum(zeit) "time (min)"   (select b.length distance, b.length/b.maxspeed_forward*60 zeit     pgr_dijkstra('select gid::integer id,                             source::integer,                             target::integer,                             to_cost cost,                             reverse_cost                      ways',                      728126, 508421, true, false) a,                      ways b   a.id1=b.gid::integer) routing; 

the returned distance 232.388203319894 km , time in minutes needed trip 275.537860166885 minutes.

i tried calculate same route @ openstreetmap, , here getting longer, faster route returned. therefore, know if doing correct things here or not.

also, when use 'cost' column import data osm2pgrouting instead of 'to_cost' column, getting 123.397950457207 km, no matter if reverse_cost true, or false.

using 'to_cost' column , turning reverse_cost true getting distance of 143.048209059395 km, , time value of 169.415916099922 minutes back.


Comments