Renames Avoid intersection to Avoid overlap [needs-docs]

[SrNetoChan]

Description

In a training session one of my students point me to the fact that, in the snapping toolbar, the term intersection is used with two different meanings, making it confusing to understand/use.

I think his comment makes sense. In the main toolbar we have an option called snap on intersection. That seems good, and I don't think there's another word for it.

In the advanced options, for polygon layers, theres a "Avoid intersections" option. I think that more than intersections, we want to avoid overlaping polygons.

My proposal is to rename "Avoid intersection" to "Avoid overlap", which seems more accurate (when compared with other tools like the topology checker) and fixes the confusion.

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

• Commit messages are descriptive and explain the rationale for changes
• Commits which fix bugs include fixes #11111 in the commit message next to the description
• Commits which add new features are tagged with [FEATURE] in the commit message
• Commits which change the UI or existing user workflows are tagged with [needs-docs] in the commit message and contain sufficient information in the commit message to be documented
• I have read the QGIS Coding Standards and this PR complies with them
• This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
• New unit tests have been added for core changes
• I have run the scripts/prepare-commit.sh script before each commit

[SrNetoChan]

@nirvn @wonder-sk @3nids would love your opinion on this. Thanks

[wonder-sk]

My opinion is that "avoid intersections" is not a great name, "avoid overlaps" is better, but it really means "avoid overlaps of newly added and reshaped geometries" :-)

One thing that always puzzled me was why this option is within the snapping configuration when it has nothing to do with snapping... (this has been the case since the feature has been added long time ago)

For this PR I'm 0 - the improvement requires updates of documentation and ideally also underlying code changes to keep the terminology consistent between code and GUI... (which would involve api break)

[stale]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[stale]

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist.

[SrNetoChan]

Can we reopen this? I was still waiting for comments.

Although I agree with @wonder-sk that this feature is not a perfect match for the snapping properties, I can imagine a better-suited (practical) place for it.

Has it is, I think we still have a problem with the naming using intersection for very different concepts.

About the possible API break if we cascade the changes to class names and so on, can't we just push that for when we can do an API break and change the labels anyway. I will take care of updating the Documentation in case this PR goes forward.

@DelazJ @nyalldawson any opinion on this?

[DelazJ]

@SrNetoChan I agree with you that we should fix the misleading label now (which is an end-user issue) and devs would adapt the methods renaming/moves when suitable for API breaks.

[m-kuhn]

@SrNetoChan I agree with you that we should fix the misleading label now (which is an end-user issue) and devs would adapt the methods renaming/moves when suitable for API breaks.

👍 API freeze shouldn't block GUI glitch fixes