Opened 6 years ago

Closed 6 years ago

#1234 closed defect (fixed)

pgRouting: PostGIS database ways table bad import os OSM data

Reported by: hamish Owned by: dkastl
Priority: critical Milestone: OSGeoLive7.0
Component: OSGeoLive Keywords: pgRouting
Cc: dkastl, live-demo@…

Description

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

Attachments (1)

pgrouting_7.0rc2.png (96.2 KB) - added by hamish 6 years ago.
pgrouting postgis ways table coming back to common point in the NE

Download all attachments as: .zip

Change history (7)

Changed 6 years ago by hamish

Attachment: pgrouting_7.0rc2.png added

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

comment:1 Changed 6 years ago by hamish

Cc: dkastl added

comment:2 Changed 6 years ago by dkastl

Owner: changed from live-demo@… to dkastl
Status: newassigned

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

comment:3 Changed 6 years ago by hamish

Cc: live-demo@… added

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

comment:4 in reply to:  2 Changed 6 years ago by 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

comment:5 Changed 6 years ago by 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

comment:6 Changed 6 years ago by dkastl

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.