Add trim distance start and end to Hashes/Markers line symbol layer

[troopa81]

This extends capabilities already existing for simple line to hashes and markers line symbol layers.

Funded by Stadt Frankfurt am Main and Oslandia

[troopa81]

One could argue that the "offset along line" was already allowing to trim at the start. However, it was not possible to trim at the end. I'd rather have trim start and end (instead of having just end):

• To have the same widget than simple line symbol layer
• To have a symmetric widget and avoid confusing user that would search for start trim when seeing end trim.

@nyalldawson May I request your opinion on this?

[github-actions]

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 86ad301)

🍎 MacOS Qt6 builds

Download MacOS Qt6 builds of this PR for testing.
This app is not notarized, run sudo xattr -d com.apple.quarantine /Applications/QGIS*.app to avoid the warning
(Built from commit 86ad301)

[nyalldawson]

One could argue that the "offset along line" was already allowing to trim at the start. However, it was not possible to trim at the end. I'd rather have trim start and end (instead of having just end):

To have the same widget than simple line symbol layer
To have a symmetric widget and avoid confusing user that would search for start trim when seeing end trim.

Hm, tricky question! As far as I can tell the differences are:

• offset along line supports negative distances, at least on the interval placement mode (shame it doesn't support it for on start vertex/on end vertex). Trim mode doesn't support negative distances at all (to eg extend out the line (again, it'd be nice if we added that some day)).
• offset along line ISN'T supported at all for "on central point", but trim start WOULD permit a central point marker considering only a substring
• Having a marker offset along line DOES consider the "skipped over" bit of the start of line when calculating an average angle for the marker. Trimmed start wouldn't have knowledge of the skipped bit, so the average angle won't consider that at all

I personally think there's enough of a difference in behavior to justify having the two as separate options. I think it just becomes a matter of ensuring there's appropriate detail in the tooltips and QGIS documentation to help avoid user confusion.

[signedav]

Two inputs. But otherwise code looks good and I tested it successfully.

[troopa81]

I personally think there's enough of a difference in behavior to justify having the two as separate options. I think it just becomes a matter of ensuring there's appropriate detail in the tooltips and QGIS documentation to help avoid user confusion.

OK, I've added some tooltips to make it more explicit

[signedav]

So I guess this is good to merge?

[nyalldawson]

I would like to review first please

[qgis-bot]

@troopa81

This pull request has been tagged for the changelog.

• The description will be harvested so please provide a "nearly-ready" text for the final changelog
• If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
• If you can, it's better to give credits to your sponsor, see below for different formats.

You can edit the description.

Format available for credits

• Funded by NAME
• Funded by URL
• Funded by NAME URL
• Sponsored by NAME
• Sponsored by URL
• Sponsored by NAME URL

Thank you!

[qgis-bot]

@troopa81
This pull request has been tagged as requiring documentation.

A documentation ticket will be opened at https://github.com/qgis/QGIS-Documentation when this PR is merged.

Please update the description (not the comments) with helpful description and screenshot to help the work from documentors.
Also, any commit having [needs-doc] or [Needs Documentation] in will see its message pushed to the issue, so please be as verbose as you can.

Thank you!

[github-actions]

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.

[signedav]

@troopa81 could you resolve the conflicts to be ready to merge as soon as Nyall gives his final review?
This should really be merged because the already merged styled depend on it...

[signedav]

@nyalldawson, I saw you’ve frozen the PR. Should I ask someone else (e.g., Matthias or Mathieu) to take a final look if you’re short on time? I think it should be on the release because of the already merged default styles (otherwise we will have to revert it)...

[troopa81]

@troopa81 could you resolve the conflicts to be ready to merge

Done

[nyalldawson]

@signedav at this stage were still officially releasing in a few hours. I don't think we should be merging any features now.

[signedav]

Fair enough. But do you think it's realistic to get this into 4.0.1? If not, I'd suggest reverting #64555 (maybe after release to not risk anything) because the styles are not valuable without this.

[nyalldawson]

@signedav let's just wait for now, see if there's a call made on pushing back release and then re-asses