pgRouting: PostGIS database ways table bad import os OSM data

[hamish]

Hi,

moving this into its own ticket from #1233.

• connect to pgrouting PostGIS database in QGIS works, but the ways table doesn't look very healthy, all links back to one spot. or maybe that is the shortest path from a->b? as-is doesn't look healthy anyway. see screenshot.

I can confirm that the "all links back to one spot" problem in the pgrouting PostGIS db was not present in the 6.5 version of the live disc, so this is a new pgRouting problem too. (& perhaps a separate issue to the TinyOWS failure)

I'm guessing that it can only mess up the routing results.

thanks, Hamish

[hamish]

pgrouting postgis ways table coming back to common point in the NE

[dkastl]

Thanks for reporting this. Did you run any query? Or is it just the table opened in QGIS? I will take a look.

[hamish]

I just had a look at the visualization of the data in QGIS, I didn't try running a query and comparing the result with a straight line path.

thanks, Hamish

[hamish]

Replying to dkastl:

Thanks for reporting this. Did you run any query? Or is it just the table opened in QGIS? I will take a look.

ping

thanks, Hamish

[hamish]

Hi,

just an update on the situation -- Daniel suggested that it might be a 32bit problem as it seems to test ok on 64bit ubuntu. OSM passed the 32bit integer limit for feature ID a couple months ago so that may be the culprit. The best thing would be to solve the bug in osm2pgrouting (if in fact that's where the bug is :), but for the live disc on a deadline or for a workshop with the 7.0 disc, perhaps some magic Postgres command to delete lines connected to the one problematic node could help, or have someone run the import on a 64bit ubuntu, dump the resulting DB to a file, then reimport the DB on the live disc as part of the build process.

?

thanks, Hamish

[dkastl]

Issue was fixed in osm2pgRouting. Should be included in the latest osm2pgrouting Ubuntu package.