wxGUI/vdigit: clean zero-length vector map boundaries before start editing

[tmszi]

Fix bug reported in the issue #488.

[petrasovaa]

I didn't actually test this, so this is not a full review yet, but I would be concerned here that the extensive topology checks which would be called every time you start editing would take a lot of time. Ideally we could figure out (somehow, I don't know how at this point) something is wrong and then try v.build -e.
It would be good to find out why the zero-length boundaries actually crash the GUI.

This should in any case go into separate function for readability.

g.remove is not needed, g.rename with overwrite will do the job.

[tmszi]

I didn't actually test this, so this is not a full review yet, but I would be concerned here that the extensive topology checks which would be called every time you start editing would take a lot of time. Ideally we could figure out (somehow, I don't know how at this point) something is wrong and then try v.build -e.

Yes of course. I have seen how the check of zero-length lines is solved in the C function Vect_topo_check() and I use this functionality in my _topoZeroLengthCheck() method.

It would be good to find out why the zero-length boundaries actually crash the GUI.

wxWidgets StrokeLines() function complain:

Traceback (most recent call last):
  File "/usr/lib64/grass79/gui/wxpython/mapwin/buffered.py",
line 593, in OnPaint

self.pdcVector.DrawToDCClipped(gcdc, rgn)
wx._core
.
wxAssertionError
:
C++ assertion "n > 1" failed at /var/tmp/portage/x11-libs/wx
GTK-3.0.4-r302/work/wxWidgets-3.0.4/src/common/graphcmn.cpp(
742) in StrokeLines():

Zero length line/boundary has only one point (start == end) and therefore it is raise C++ assertion "n > 1 (n -> number of points) error.

wxGUI doesn't always crash. Map rendering during editing is incorrect, due to wxWidgets StrokeLines() function assertion error (screenshot from editing #488). Rendering start working during editing if you zoom in the region which doesn't contains zero length lines/boundaries.

This should in any case go into separate function for readability.

All right.

g.remove is not needed, g.rename with overwrite will do the job.

Thanks. I fixed it.

[neteler]

@tmszi @petrasovaa can this be merged?

[petrasovaa]

@tmszi @petrasovaa can this be merged?

I haven't had time to review it. Did you test it? In any case, I am not sure it's a good idea to backport it, the problem it fixes is rather obscure.

[neteler]

@tmszi @petrasovaa can this be merged?

I haven't had time to review it. Did you test it?

I think I did but it is too long time ago.
A test dataset is available here: #488 (comment)

In any case, I am not sure it's a good idea to backport it, the problem it fixes is rather obscure.

ok I see.

[neteler]

I finally have been able to test this PR. It works nicely, see also the new screenshots in issue #488.

Thanks a lot, @tmszi. Please merge if there are no further objections.

[wenzeslaus]

@tmszi and @neteler I might be late to the party, but here is my take on it.

The original report by @neteler describes the crash being caused by previous crash. Notably, this does not resolve either, but it mitigates the problem by requiring and ensuring clean topology (at least for that particular invalid messy topology case). Please, note this in the merge commit (and perhaps the PR description too). In other words, to require some cleaning before editing is probably fair enough (although messy data might be the very reason I want to edit the vector manually, no?), however it needs to be clear that the code would still crash if the data is not as expected.

There are some minor issues with the code, but the major issues I see are adding this type of code to already overloaded, and possibly misused, toolbars.py, adding analytical code to GUI, and adding another direct access to ctypes. I try to discuss in the comments what I mean.

[wenzeslaus]

The code in this function should probably be a separate module. It should not be part of GUI because it is data processing. In general, we should be moving any processing and analytical code from GUI. The idea is to keep the GUI as small as possible while making all functionality available in GUI also available for scripting ideally in command line or at least in Python. This also allows for easier testing of the functionality both in terms of writing tests and manual testing in case of debugging an issue.

[wenzeslaus]

The use of ctypes and the generated ctypes interface to libraries is tricky already at the import level. Other places in GUI which do this are (or should be) very careful about import. It is best to completely avoid this in GUI and solve it in a separate module (in Python or C).

[wenzeslaus]

This is kind of border line case here. This calls modules, so it is okay in GUI in general and there is already v.build call here, but on the other hand, this file is toolbars.py. Something to consider. Maybe refactoring is needed if there is more stuff needed than just one v.build call.

[wenzeslaus]

Translatable strings can't have sentences constructed from words. You need multiple messages or part of the message which is not a sentence but some {x}: {y} type of report or table. There is also a way how to change a message with support of the gettext package based on the number, but I don't know how to easily use it in Python with our suboptimal translation handling (that is _ added to buildins).

[wenzeslaus]

This function is already long, but if we add all these lines with two new return statements and at least six branches, it will be only harder to maintain later. If you stay with this solution, I suggest refactoring or shortening the code needed right here.

[wenzeslaus]

The one return statement above returns None, but the three down below return boolean. Pylint should give a warning about that.

[petrasovaa]

#1989 fixes the crash described in #488 (merged and backported to 8.0). This PR offers an automatic check and fixing before editing, so it may be nice from user point of view, but it adds a lot of code in GUI for a very minor case and I wonder how it would perform with large vector maps.