search

pgRouting / osm2pgrouting

Import tool for OpenStreetMap data to pgRouting database
https://pgrouting.org
GNU General Public License v2.0
286 stars 113 forks source link

length, cost and reverese cost is not a valid distance #275

Open Langlaeufer opened 4 years ago

Langlaeufer commented 4 years ago

length is calculated with pythagoras function for planar metric coordinates. osm data has geographic coordinates (angles). The distance function gives wrong values for distance, because the distance between meridians gets smaller from equator to pole. the length value is also used in the colums cost and reverse_cost.

maybe it is included to use with A* ? otherwise it may be better to remove this wrong distances. please add columns const_m and resverse_const_m to the table.

cayetanobv commented 4 years ago

This issue was discussed a long time ago here: https://github.com/pgRouting/osm2pgrouting/issues/8

Langlaeufer commented 4 years ago

yes, the last post was my point. length in degree calculate on a Plate Carree I was asking me if the distance in degree is needed for A*-Funktion to approximate air line, because also start and end node are given in degree. length in meter is already stored in the table, it only needs to add also cost, reverse cost in meter.

cvvergara commented 4 years ago

Once data is loaded into the database you can use postGIS to calculate haversine distance for exampĺe

Langlaeufer commented 4 years ago

yes, in postgis I can calculate all lengths, times, coordinate-values. So the question is, why are some columns present and others often needed not. I would assume the normally metric length (distance on the spheroid) and the resulting time is used as cost function for routing algorithms. Because of the missing documentation I have to guess: I guess the distance in degree is a hack to let the A* function work with geographic coordinates. I can't find any other reason for using the distorted Plate Carree degree length instead of correct spheroid length. Even spherical length would be better.

dkastl commented 4 years ago

What about dropping all length computation, that osm2pgrouting does, and leave it up to the user to decide what they want? It should be rather simple to do this with a bit of PostGIS as mentioned before.

This means less documentation and no confusion ;-)

I actually always had the impression, that there was some length taken from OSM data, but I must admit that I never checked if it's really the case.

Langlaeufer commented 4 years ago

To remove everything specific which can be easily calculated from the database would make it much more generic and easier to understand.

The basic values in table ways are: gid, osm_id, tag_id, name, source, target, one_way, maxspeed_forward, maxspeed_backward, geom. All other values can be added via SQL.

These values would be helpful to start with dijkstra (but can be calculated via SQL) lenght_m - from ST_length(geom,true) cost_m - from length and oneway reverse_cost_m - from length and oneway

maxspeed and time are only working for car navigation: cost_s - from const_m and speed reverse_cost_s - from reverse_const_m and speed

This is for using original OSM ids osm_source, - lookup in ways_vertices osm_target - lookup in ways_vertices

I guess this is for A* (when using with geographic coordinates) x1,x2,y1.y2 - ST_X, ST_Y, ST_StartPoint, ST_EndPoint length and cost (in degree) -- ST_length(::geomerty) and Oneway

In all case a small tutorial how to calculate distance, time and also how to consider access and roadtype would be great. And of course a documentation that describes what the program is really doing.