length, cost and reverese cost is not a valid distance

[Langlaeufer]

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]

This issue was discussed a long time ago here: #8

[Langlaeufer]

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]

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

[Langlaeufer]

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]

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]

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.