Hi all, Note this is in the WXPYTHON GUI
I have been digitising vectors, using tools including add new boundary or centroid, move vertex, delete vertex, split line, probably a few others too. Most of the time no problems, but I just had GRASS crash (all windows disappeared, only the 'terminal' I started it from still open) after using the split tool, then using the 'delete vertex' tool. I selected a boundary vertex to delete (left-mouse click), then on right-click to confirm, it all crashed. When I have just started up GRASS again, I found that vector had boundaries and centroids, but the areas were not shaded. when I started the digitiser mode, it gave me the 'no topology' message. I clicked OK to rebuild, and it crashed again, though in the terminal I noted the usual output from when topology is rebuilt (e.g. number of boundaries, centroids, number of areas without centroids, etc). Upon starting GRASS a third time, I found that vector still did not have topology. I used the v.build (rather than just asking it to rebuild prior to digitising). This seemed to recover my vector correctly, and did not cause a GRASS crash. I found one area that seemed to have 'lost' its centroid though. I was checking the data (in digitising mode) for the areas I'd digitised before the crash, they seemed in order, then I used the pan tool (about the third time I'd used it whilst in this digitising session) to move towards the part of the map where I'd been working at the time of the initial crash, and GRASS crashed again! Upon starting up GRASS AGAIN! I found that vector had lost topology AGAIN. run v.build again, seemed to correct the problems, tried to open up digitiser mode and it crashed AGAIN. Did a shut-down and restart of my computer. Another GRASS session - had to do v.build again, then it crashed when I tried to enter digitiser mode and select that vector layer. Went back to running GRASS in tcltk. Had to do v.build on the vector in question, but could open it for editing with v.digit. I got a message upon running v.digit that "Coor files of vector map <GRT11_12@Lacebark> is larger than it should be (1113 bytes excess)" Which I understand as I've come across this sort of message before when vectors have been corrupted or there's erroneous boundaries/centroids etc floating around from a job part-done before a crash. Why though, has this occurred in the first place (i.e. the initial crash and loss of topology when using 'move vertex' tool in digitiser)? It seems all the crashes that followed in wxgui when I tried to get back to the vector to correct/digitise may have been caused by this coor file error, but the wxgui didn't tell me that, it just crashed repeatedly. at least the tcltk gui has told me of this problem, so now I could get on to fixing it with v.digit. I tidied up the boundaries/centroids where I'd had the crash, found a single-point boundary in existence under one of the vertices of a 'proper' boundary, not sure how or when this could/would have been created. But along with some unclosed boundaries and centroids in these unclosed areas, I got it tidy, and tried wxgui again. HOORAY! I can digitise again in wxgui, it didn't crash! Now, this experience is currently too longwinded to report as a bug, does anyone else have some suggestions on what parts would be the relevant bits if I was to report this as a bug? do I need to run GRASS and replicate the problem with 'debug' mode or something to get more useful output on what's happening? Feedback appreciated. As a footnote - I don't mind persevering with 'newer' GRASS versions to help figure out glitches etc, but it is frustrating when the glitches I find cause substantial loss or corruption of my data. I do have irregular manual backups, but even losing half-an-hour's worth of work between backups, and taking twice as long to check/restore/redo it all is precious wasted time for me. Does anyone else have a protocol (maybe an auto-save to 'filename-dateextension') to reduce their data loss / downtime when testing out newer GRASS setups on their system? -shane. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user