OSM data consistency
Status: Pre-Alpha
Brought to you by:
sakaal
Menu
▾
▴
#14 OSM data consistency
In recent testing with Osm2postgis Rev 83 and the latest pgrouting source externalized for use outside of postgresql using std sql queries, I've encountered some data consistency issues that may be causing pgrouting to bomb when it creates routing graphs using boost c++. I've seen similar crashes using internalized pgrouting lib via the SPI api. This includes using Win dlls built and distributed via the pgrouting project.
Whether the following is contributing to boost crashes (array out of bounds errors during graph creation) can be questioned, given how it appears boost will use these data:
1) ways with zero length, zero cost, zero reverse cost and identical start/finish geodetic points
2) ways with duplicative source, target, cost, reverse cost, and geom (only the id and way number are different)
I've attached a screen cap from pgAdmin. Rows 1-9 show the zero cost ways. Rows 17 and 18 show what appears to be a duplicative way.
I am unfamiliar with the data constraints imposed by boost. But the foregoing seem suspicious. Question: is it necessary for osm2postgis to prevent either of these cases?
I've come across another case of possible consistency errors with navigation_motor. This time the way, source, target, x1,y1,x2,y2 are identical, but length, cost, and reverse_cost do not agree with the duplicative row. Please see attached md_routing_navigation....png images for the sql used and results.
I think it might be a good idea to do some sanity checking with OSM2PostGIS. Although OSM data is of relatively high quality, it's still not good enough to be used as is for many purposes. So, it's a good thing if you can report the kind of oddities that are causing the most headache.
This link provides insight into where some of the data anomalies may be originating from:
http://matt.dev.openstreetmap.org/dupe_nodes/about.html#errors