[metzm]

From the updated manual:

When overlaying two vectors with areas, very small areas can occur in the
output. This can happen when e.g. one vector is a slightly modified
version of the other vector (buffered or simplified). These very small
areas can be removed by setting minsize to some value larger 0.
The value is interpreted as square meters. In order to remove only noise
from slightly mismatching boundaries, the value of minsize should be
small, e.g. in the range 0.0001 to 1.

This is useful not only to remove noise, but also to reduce the size of the output vector in cases where a lot of very small areas are created by the overlay operation.

The group of PRs #7333, #7338, #7366, #7370 belong together.

[metzm]

The new test contains two tests:

• no cleaning, thousands of very small areas, some are so small that a centroid can not be calculated, but with lib/vector: improve numerical stability for point-in-polygon calculations #7333 G86 manages to calculate more centroids than G84
• with cleaning, including the new option to remove small areas.

The second test is relatively slow, together they take 10.7s on my laptop which I find a bit long for the whole GRASS testsuite. Any opinion on the test duration?

[echoix]

Limit to 2-3 polygons maybe? We wish to have unit tests, not really integration tests

[metzm]

Limit to 2-3 polygons maybe? We wish to have unit tests, not really integration tests

OK, running time is now down to 1.5s, I think this is ok. My statements about the new tests still hold true.

[metzm]

There are now unittest tests and pytest tests. Both do the same tests. Delete the unittest tests?

[echoix]

There are now unittest tests and pytest tests. Both do the same tests. Delete the unittest tests?

Yes if possible. Or, to solve the failures, rename one of the files. But if they are both the same test, only keep pytest

[metzm]

Does anybody have any idea why the pytest fails at the very first GRASS command?

It succeeds locally, otherwise I would not have added this pytest. Because the failure is not reproducible, I have no idea how to fix it.

[echoix]

Yes, there’s something weird made as a side effect of calling something of the c-based library or tools, that make it fail on the first call (per worker). Then, next calls are working as normal. Python side doesn’t seem affected.

I didn’t manage to find out what magic is done yet in more than 2 years. This behavior is even more apparent when randomizing the test order. And on windows it’s worse, (from my experience), as more tests can fail.

[echoix]

If you find out why, it would unblock many things

[echoix]

In the pytest error trace, for Linux, it makes additional mention of no active grass session, GISRC env var isn't set

Here:

ERROR: No active GRASS session: GISRC environment variable not set

So, not creating the temp project for the data setup fixture would be a good hypothesis, see the PR review comment.
But you would probably not have access to the demo project by default (which we avoid for pytest for now).

[metzm]

The requirements for a meaningful test are that the test must fail with GRASS 8.4 with regard to the number of centroids because GRASS 8.6 is able to create centroids for edge cases where GRASS 8.4 fails. In GRASS 8.6, the number of areas should be higher and the number of islands should be lower than in GRASS 8.4.
These differences come from improvements to the GRASS vector library mentioned in this PR's description.

Synthetic test data do not catch these differences, therefore the test will be reverted from pytest to GRASS unittest using real-world data able to verify improvements in the addressed edge cases.