+----------+-----------+ | relation | to_node | +==========+===========+ | 11411 | 0 | | 13583 | 0 | | 13583 | 1 | | 14176 | 0 | | 14341 | 0 | | 14906 | 0 | | 103616 | 365162762 | +----------+-----------+
+----------+----------+ | relation | to_way | +==========+==========+ | 20869 | 32431618 | | 78013 | 23859754 | | 78837 | 7012683 | +----------+----------+ Clean, gone and updated. One thing for sure; we can blame the subject or its tiny helpers again. I have no clue why the exclusive tool can add members that were invisible at 2009-03-28T12:29:01+00:00 back to an update to the relation at: 2009-03-29T17:39:59+01:00. Potlatch works in mysterious ways. For more fun try this: http://api.openstreetmap.org/api/0.5/relation/20869/history I really wonder, considering the claims of the software that I am using right now, if the API 0.6 upgrade adds referential integrity at 10x the cost I see now, boy, that will be unworkable, considering that this is already running on a 64GB system. ...and just got the report back that another 4756 of broken way/nodes are present. A random sample: | 32641224 | 346797292 | | 32641224 | 346797293 | | 32641224 | 346797296 | | 32641224 | 346797298 | | 32641224 | 346797299 | | 32641224 | 346797302 | | 32641224 | 346797304 | | 32641224 | 346797305 | | 32641224 | 346797306 | | 32641224 | 346797308 | | 32641224 | 346797309 | | 32641224 | 346797310 | | 32641224 | 346797312 | | 32641224 | 346797314 | | 32641224 | 346797316 | | 32641224 | 346797317 | | 32641224 | 346797318 | <osm version="0.5" generator="OpenStreetMap server"> − <way id="32641224" visible="true" timestamp="2009-03-29T18:13:05+01:00" user="Rutger"> <nd ref="366972611"/> <nd ref="346797319"/> <tag k="created_by" v="Potlatch 0.10f"/> <tag k="highway" v="unclassified"/> <tag k="smoothness" v="intermediate"/> </way> </osm> http://api.openstreetmap.org/api/0.5/node/346797302/ways Just maybe; someone with SVN rights consider the direct removal of this evil tool. Especially from the edit button; considering this comment in the previous thread: "The typically accepted 'fix' for these is to modify the way in Potlatch, which, as a byproduct of it's method of rewriting all related objects, restores the nodes to their prior undeleted state... To blindly rewrite these damaged ways removing the problem nodes would hide the problem but could leave the way itself inaccurate... These ways should be manually inspected to work out what the actual problem is and to repair it, or at the very least, a lot more logic needs to be used in any automated process..." If my hammer damages my wood, maybe I should use a different hammer, instead the same hammer to repair it. If my wood is fundamentally broken... http://api.openstreetmap.org/api/0.5/way/8171646 http://api.openstreetmap.org/api/0.5/node/80175/ways http://api.openstreetmap.org/api/0.5/node/80169/ways ...considering data corruption *IS* an option. The following ways (79) are broken: 8171646 8608847 10507178 22719530 23839430 24582092 25568800 26461202 27547015 28789811 32349559 32454514 32454515 32461705 32464860 32464885 32466337 32468049 32468177 32468403 32469946 32469953 32470768 32471765 32472879 32473568 32474905 32475217 32479496 32484068 32485041 32485430 32485442 32485448 32485452 32487347 32491777 32491986 32491998 32492393 32493200 32493648 32497949 32500676 32500683 32501668 32504849 32506804 32507955 32509470 32509471 32511892 32511894 32518617 32521266 32521780 32530130 32557665 32558085 32572084 32573697 32592750 32599977 32601140 32601701 32602765 32602769 32602861 32606393 32608171 32620318 32620841 32630852 32640605 32641086 32641224 32641658 32643170 32643612 Stefan _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
