The xml configuration files

[cvvergara]

Right now there are some configuration files: mapconfig and mapconfig_for_cars @robe2 says: " when I use, it I get nothing for this query:

SELECT r.seq, r.node, w.name As street,  r.cost, 
   SUM(w.length_m) OVER(ORDER BY r.seq) As dist_m
 FROM pgr_dijkstra('SELECT gid AS id,
                         source,
                         target,
                         cost, reverse_cost
                        FROM ospr.planet_ways',
 (SELECT id FROM ospr.planet_ways_vertices_pgr ORDER BY the_geom <-> 
        ST_SetSRID(ST_Point(-77.0364906,38.8975428), 4326) limit 1 ) , 
 (SELECT id FROM ospr.planet_ways_vertices_pgr ORDER BY the_geom <-> 
        ST_SetSRID(ST_Point(-77.0227327,38.8877948), 4326) limit 1 ), false) AS r
        LEFT JOIN ospr.planet_ways AS w ON r.edge = w.gid;

But get answers when using the mapforcars config I also get an answer with similar query using osm2po"

[cvvergara]

@robe2

• cost, reverse_cost get the CRS length (I cheched and its the same result as ST_length(the_geom) but on on ways streets (one_way = 1 or one_way = -1) the value will be negative. So the edge in a directed graph is not included.

• cost_s and reverse_cost_s are time costs, which depend on speed, maxspeed_forward and maxspeed_backward, of the edge and in length in meters length_m of the edge.

  time = distance / (speed * 5/18) (the 5/18 are to convert the km/hr speed to m/s)

• do you think its useful to have cost_m, and reverse_cost_m, based on length in meters? That way the query you are posting can be smaller.

[cvvergara]

Or maybe use pgr_pointtoedgenode

[robe2]

I think having cost, reverse_cost in seconds would be nice feature.

[MarHoff]

Just stumbled into this thread while seeking about How to quick-fix drive time in residential area with Osm2PgRouting?. This thread helped me a lot understanding how _costs & _reversecosts work before digging into the code, so thank you ;)

About the issue, as I began to use osm2pgrouting having _costm and _reversecostm would have been nice features. Because for instance when you first use _pgrdrivingDistance to calculate a range in meters it's not so easy to understand at first that you have to do some CRS conversions to set the distance parameter.

However it's more like a nice to have feature than a really missing one.

[cvvergara]

@MarHoff latest version has length_m also there is a column about the geometry direction (one_way), so: cost_m and reverse_cost_m can be set in postgres based on the values of one_way.

[MarHoff]

As I said, once you are familiar with the tools no big deal, but it does have a learning curve because you'd have to take various case in account as stated here

• 0 unknown,
• 1 yes(normal direction),
• 2 (2 way),
• -1 reversed (1 way but geometry is reversed)
• 3 reversible (one way street but direction chnges on time)

So whereas cost & reversecost can be used out of the box you need to dig into the data-model to derive a _costm properly. But it's exactly the same deal (maybe even worst) with _costs & _reversecosts that need some tweaking to give realistics estimations.

But osm2pgrouting being a great FOSS tool I totally get that you "still have to earn it a little" and that plug & play isn't exactly on the current roadmap ;)

[cvvergara]

There is always a learning curve in everything:

• little learning curve: osm2pgrouting, osm2po etc
• big learning curve: postgis, pgrouting

[MarHoff]

Ok, sorry to have digged this thread for bad reasons. While content here helped me a lot, it was already a bit off topic, sorry again.