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
