Topology created by osm2pgrouting leaves some ways with identical source and target nodes, making them un-routable

[robhawkes]

After running osm2pgrouting on the Greater London OSM data (listed below) I'm left with a bunch of ways in the ways table that have an identical node id for both the source and target. This makes those ways un-routable, even though the ways seem completely legit and aren't broken in OSM.

The only thing I can think of that may be triggering this bug is that the affected ways are so short (length values in the database of less than 0.00…).

Any ideas? I'd like to see this fixed but in the meantime I'd be happy to settle for a short-term workaround.

Further info

• OSM Data
  • http://download.geofabrik.de/europe/great-britain/england/greater-london.html
• Example way exhibiting issue:
  • GID 420764 (OSM_ID 165256657) in generated ways table
  • SELECT * FROM ways WHERE gid = 420764
• 354 ways with the same issue
  • SELECT * FROM ways WHERE source = target

[robhawkes]

Currently experimenting with different snapping tolerances on the pgr_createTopology function. Will report back with findings.

[robhawkes]

Ok, ran the following (changing the tolerance in Export2DB.cpp from 0.00001 to 0.0000001):

SELECT pgr_createTopology('ways', 0.0000001, 'the_geom', 'gid');

Followed by:

SELECT pgr_analyzeGraph('ways', 0.0000001,'the_geom','gid','source','target');

Which stated that the topology was "OK"

Now there don't seem to be any ways with the same source and target, as verified by running:

SELECT * FROM ways WHERE source = target

I need to continue testing to see if this causes any other problems with my routes, but so far so good.

[dkastl]

Thanks for looking at this. The "snapping tolerance" is an attribute of the pgRouting function and if there exist tiny ways as you mention, then this looks like a data issue. If these ways are valid though, then the tolerance needs to be smaller.
But this means that other areas, where mappers are not careful with connecting ways would get disconnected networks.

Probably it would be best to make the snapping tolerance an optional parameter of osm2pgrouting.

[robhawkes]

The ways mentioned were definitely legitimate (tiny bits of road wedged between 2 slightly-offset junctions), however I understand that changing the tolerance has an impact on others who may not have these issues.

Having the tolerance as a user-definable parameter (and mention in the documentation) would be perfect.

[cvvergara]

With the alpha version this no longer happens
Test on Washington dc area:

select gid from ospr.ways where source = target;
 gid 
-----
(0 rows)