Calculation of way length incorrect about osm2pgrouting HOT 17 CLOSED

Not sure why the length is calculated that way. It's not so difficult to run later UPDATE ways SET length = ST_Length(the_geom) for example.

from osm2pgrouting.

Just noticed this too, here is a suggested workaround that take in account the reverse cost.

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;

As it's based on the spheroid instead of a local projection this should be working for anyone.
Also notice that i send the result in 3 different columns.
lentgh --> always the absolute length
to_cost --> length pondered ( useful if a one-way street was declared as reversed oneway=-1)
reverse_cost --> length pondered

So when using any pgrouting function use the column 'length' if you dont want to take account of one-way and the column 'to_cost' when you also use 'reverse_cost' .

Edited thanks to @woodbri

from osm2pgrouting.

I think there is a general assumption that geometry is in WGS84 projection. Assuming that there are not other places that this assumption is made, we could probably change:

ST_Length_Spheroid(the_geom,'SPHEROID["WGS 84",6378137,298.257223563]')

to:

ST_Length_Spheroid(st_transform(the_geom, 4326), 'SPHEROID["WGS 84",6378137,298.257223563]')

or:

ST_Length(the_geom::geography)

I think we assume that we are getting results as meters.

from osm2pgrouting.

Thanks, I must confess i still work with 'geometry' type and I'm not fully aware of these tricks with 'geography' type :P
I'll edit previous post

from osm2pgrouting.

Although there is this function st_length() as stated by@dkastl to consider the sphericity of the edge also, not just the great-circle distance between the nodes as what osm2pgrouting is doing; how to entertain the elevation variation also between the nodes, let's say a hilly terrain, for more precision?

from osm2pgrouting.

@Zia- I'm not aware of OSM data providing terrain information. But if you have terrain data in your database and because you know the road geometries, you have the ability to recalculate the length more precisely if you want to do so.

That said, I don't think osm2pgrouting needs to do this.

from osm2pgrouting.

@dkastl Since we have free DEM access of SRTM90m (http://www.cgiar-csi.org/data/srtm-90m-digital-elevation-database-v4-1#download) and ASTER30m (http://gdex.cr.usgs.gov/gdex/), I was expecting more precise length estimation, using some APIs or something, in the upcoming osm2pgrouting versions.

from osm2pgrouting.

@Zia- I don't think that is osm data.

from osm2pgrouting.

@cvvergara - No no, definitely not. I am even not sure if these NASA and JAXA products have any API also to be used for this purpose. I was just wondering. Apologies if that was silly.

from osm2pgrouting.

@Zia- I like the idea to use terrain data for more precise length, but I think this should not be part of osm2pgrouting for the following reasons:

• OSM data does not contain terrain data
• Calling an API would significantly increase the processing time. You even risk to get black-listed.
• Probably not everyone needs it

I think it's a nice idea to provide some tools to make use of terrain information, not only for the length. Terrain information will also be useful as cost for example when you do bicycle routing.
But let's keep this outside osm2pgrouting. It might be best to import terrain data (even raster should work) into a database and then provide special functions to make use of the data.

from osm2pgrouting.

I think the terrain information is very interesting, but does not need to be part of osm2pgrouting. Currently you should be able to load you terrain/DEM as a postgis raster and then process your edges against the raster to update the information about elevation. Postgis also has functions to compute compute 3D distances. Since this can all be done inside the database with existing tools, I do not think it makes sense to duplicate all this code inside osm2pgrouting.

from osm2pgrouting.

Agreed @dkastl @woodbri ! But would like to make following remarks.

1. Since we have intermediate vertices coordinates also in osm xml file, why osm2pgrouting is only considering starting and ending vertices coordinates for edge cost calculation? Otherwise, will atleast succeed to take into account the edge sphericity during xml import. No need to run st_length().
2. I have been working on this terrain info consideration for more precision for a while. Please check repo (https://github.com/Zia-/OSM_route_length_calculation). Approach is basically what @woodbri proposed and codes are working. I have considered nearest IDW averaging to assign DEM pixel's height values to the nearest node. I didnt use haversine formula but trigonometry cosine rule for length estimation of each edge (considering earth's radius = 6371km). Results are highly in agreement with google/yandex maps plus ground measurements which were carried out using car. But what if there is a QGIS plugin for the same?
3. Why openstreetmap editor is not considering any GDEM, behind the scene, to save elevation info also along with the node's coordinates, after each edit? So that all you have to play is with the osm xml file, if wanna attain more precision.
4. Terrain info can also be used for edge slope estimation (google maps are considering slopes for expected travelling time by pedestrians). This way one can write more specific pgRouting functions for let's say old pedestrains or cyclists, who don't wanna climb an uphill. Or can assign some edges not suitable for driving, let's say during snowfall.

from osm2pgrouting.

@Zia- These are all great comments but implementations is based on need of the developers in most cases or by funding in other cases. The current effort on osm2pgrouting is based on a GSoC student and the primary goal of this effort is to refactor the code to make it faster and easier to work with. Our hope is that the next iteration of the code will be restructured to make it easier to make some of the changes that you are suggesting.

We do not want to duplicate code, so if there is an easy way to do it using postgis, then importing the data and writing a stored procedure to add the elevation data if you need it seems like a good option.

I can't speak to a QGIS plugin, but that might be another way to solve the problem.

Also, are you aware that OSRM is doing some of the work you are suggesting via the vehicle profiles?

I understand the value of having terrain information and being able to factor that into edge cost for some use cases. We kind of view the work flow something along these lines:

1. import data (shp2pgsql, osm2pgrouting, ogr2ogr, etc)
2. optionally manipulate the data (add topology, add elevation?, compute edge costs, etc)
3. generate routes (pgrouting)

There are lots of options that can be applied at step 2. depending on your specific use cases. But if we bundle it into the loader, then we have to implement it multiple times (once for each loader). It is better to separate loading from post processing the loaded data.

You seem to have a lot of expertise in this area and a passion for it. Have you considered forking pgrouting or osm2pgrouting and contributing to the project. We would be happy to review a pull request and to work with you in designing something that is usable by the community at large.

from osm2pgrouting.

I knew about OSRM but didn't know that they are improving OSM data also via vehicle profiles.
Although I was following your conversations for a while, I am afraid to be of any help because of limited expertise in C++, but Python and Pl/pgsql. I have written custom plpgsql functions for routing. I will try to create some pull request in future regarding suggestions. Right now I am testing some plpgsql functions to solve a specific travelling purchasers problem.
I have in my mind to write a QGIS plugin to add elevation info also into ways table depending upon the available DEM data plus another plugin to locate broken edges in the osm graph for proper fixing.

from osm2pgrouting.

One thing that you could do is to write plpgsql function that that labels edges based on the connected graph they belong to. The algorithm is something like this:

1. added a column graph_id and allow it to default to null
2. select one edge that has graph_id=null and label it it as "1"
3. do a breadth first search of all connected edges and set graph_id to the same value
4. when there are no more connected edges that need to be labeled increment graph_id and locate an edge that still has graph_id=null and got to step 3
5. exit when all edges have been labeled

Now you know if all edges are connected or not and you can view the edges and color each graph based on the graph_id. This would be very helpful to visualize and/or count the number of disconnected sub graphs.

from osm2pgrouting.

@woodbri I'll start working on this tomorrow.

from osm2pgrouting.

length is in degrees, cost and reverse_cost also in degrees.
length_m is added to be in meters.
Closing, fixed in alpha.

from osm2pgrouting.