jorgegil / osm-pg-etl Goto Github PK

Currently the graph construction code is only for undirected graphs. These are useful in many cases, but for pure car networks at a smaller scale one might want to use a directed graph.

Need to develop a query to construct such a graph based on the OSM Key:oneway.

Hi,

I tested this line of code and calculated travel time and distance from a few locations to the rest of zones in Canada.
G = ig.Graph.TupleList(network,directed=False, vertex_name_attr='nodeid',edge_attrs=['edgeid','cost'])
Any particular reason to set directed as False? I tried True but it did not work. All the returned travel time and distance are inf.
With the above line of code, the travel time and distance have the below results which I think there is something wrong. Because the majority of places as origin/destination are not connected in the graph.

Routing from 1 to the rest: inf, time: 5725/9858, distance: 5725/9858
Routing from 2 to the rest: time: 9809/9858, distance: 9809/9858
Routing from 3 to the rest: time: 572/98585, distance: 5725/9858
Routing from 4 to the rest: time: 5725/9858, distance: 5725/9858

road_length = ST_AsText(geog:ways.geom::geography) somehow does not return the length in meter.

What is the difference between ST_AsText(geog:ways.geom::geography) and ST_Length(ST_Transform(linestring, 3347))? I tried the latter which gives you reasonable results. The code 3347 is adapted to Canada. And it varies depending on the country.

The linestrings in the OSM road network often don't break at every intersection. They share nodes but are not split, therefore are not correctly routeable in normal network analysis packages. This adds distance to the routes and can even isolate certain areas (create islands). The issue is more serious for short distances and for individual routes.

There are tools out there to process this: osm2po and osm2pgrouting (slower). The results are mixed, one has to understand how they work, and figure out how to configure for the desired results. My tests with osm2po show that the defaults are restrictive and returns the main car network.
Not sure how OSMNx handles this step, but worth checking.

Simply splitting the road network using geometry operations is complex and most often results in bridges and tunnels being dropped.

An approach is to "explode" the line strings at all their nodes (not adding new nodes) and stitching back together where only two segments touch. This was the earlier approach used in my 2012-15 work.

The best approach is to take advantage of the topology that is already built into the raw OSM data. The linestrings need to be reconstructed from sequences of nodes that are only present in one relation. It's similar to the above in principle, but being a topological operation should be much faster and more robust.