-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix rendering geometry generators for line layers
And add more tests
- Loading branch information
Showing
7 changed files
with
100 additions
and
41 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file added
BIN
+3.4 MB
...cted_geometrygenerator_buffer_lines/expected_geometrygenerator_buffer_lines.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+3.4 MB
...ed_geometrygenerator_buffer_points/expected_geometrygenerator_buffer_points.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified
BIN
+0 Bytes
(100%)
..._images/expected_geometrygenerator_marker/expected_geometrygenerator_marker.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified
BIN
+0 Bytes
(100%)
...ol_images/expected_geometrygenerator_mixed/expected_geometrygenerator_mixed.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@m-kuhn , playing with the generator, loving it more and more.
After several days of usage, one thing became evident: we should get rid of the Geometry Type drop down list (i.e. poygon, line point), and instead have the geometry type set according to the type returned by the expression. If the expression returned is invalid (or does not return a geometry), stick to the last valid geometry type returned (by default, it'll be the same as the layer geometry type since you begin with a simple $geometry expression).
Thoughts? @nyalldawson ?
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea sounds nice in theory, but in practice this means, that we do not only need a one feature sample of the output (as currently done for the preview below the editor) but need to be certain about what is returned.
It is well possible that not every feature returns a geometry or different geometry types are returned and in this case it needs to be possible to specify the geometry manually.
An approach would be to have a button "polygon configured but line generated, [link]change to line symbol now[/link]".
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you loop through a sample, like 10 features, and pick most returned type?
Maybe the geometry type should have an additional "Automatically determined" item which would serve as default setting. That would be more user friendly.
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And which type of subsymbol would be shown with "automatically determined"?
Would the symbol be changed silently everytime the type of the calculated geometry changes?
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the subsymbol type would match / change according to the type of calculated area, when someone finishes writing the expression by leaving the text area as to avoid switching to intermediary types while constructing the expression.
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one problem I can forsee with this: someone accidentally losing style with an accidental type change.
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the issue with the current approach? This is always going to be an advanced feature, and I think the current GUI is fine.
c9fa334
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get slightly irritated to have to manually switch type when the calculated geometry is a known type.
The current UI isn't wrong per say. Maybe it's just me testing the feature a lot, vs norma sporadic use of it.