-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
interpolated line symbol layer for vector layer #42676
interpolated line symbol layer for vector layer #42676
Conversation
Ok, first, cool :) Follow up question: why a renderer instead of a symbol layer? The latter would be more flexible in terms of cartographic possibilities. |
If this is a port, does that duplicate the code in some ways? Or if some aspects are reused, must the two be fully independent ? Though it might be nice for distance representation if length is used as the max. |
@nirvn good point! I had thinking about, but I don't remember why, there were some reasons to not make it as a symbol... Maybe I missed something... I look again. @roya0045 the rendering code is not duplicated. The base of mesh edges rendering is enough low level to be used with other rendering without implicate mesh stuff. |
The obvious gains here are that we could use the current categorized,graduated, and rule based renderer with this new symbol layer. |
@nirvn QGIS/src/core/symbology/qgssymbol.cpp Line 801 in e58a8c6
But I am not sure, for now, I do not know enough symbol layer mechanisms... I take all opinions! |
@nirvn |
I'm -0.5 to keep the renderer. If it merely serves as a way to highlight one specific symbol type vs. serving an actual technical need, then I say let's not have the renderer. There are other ways to highlight cool symbologies (e.g., you could one favorite saved symbols in our style manager, that would pop up in people's UI load and clear :) ) |
An actually, on that note, another benefit from having it as a symbol layer is being able to see those cool styles in saved style symbol previews. |
634ba36
to
4a1dc9f
Compare
Symbol layer now implemented. About the render, if I am +1, the sum is +0.5 :) |
Being devil's advocate here, wouldn't that logic have us create a renderer for all symbol layer types we like to make it simpler to access? 😉 The legend item is a fair point, yet I suspect it's possible to implement that without going down the path of a renderer. @nyalldawson would know better. |
a651cbd
to
4d6e1b8
Compare
A couple of questions jump to mind based on the below screenshot:
|
Thanks for this comments.
Here, the idea is to link extremities of line with varying value, typically field values. That why we have these field expession widgets. With simple numeric control, the idea is not exactly the same. Even the value can be overridden, in first approach for the user, it would be a fixed value, it is not the idea.
The load button load the min/max value of the field or expression "First value"/ "Second value" for all features. In case of fixed values, that will be the fixed values...
Spin boxes are behind the button: This widget is associated with the width varying, already implemented for mesh edges.
No, only one value is interpolated along the line, color and width are both |
@vcloarec 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. Thank you! |
with @wonder-sk suggestion for the GUI Only symbol layer, no renderer. @nirvn and @nyalldawson , if you are ok with this principle, I will go on this way. |
@vcloarec Could you go with tab instead of radio buttons? Having buttons change the UI is strange and unexpected. Having it as something like a tab would better indicate the change of UI. Maybe that's just me. |
@roya0045 , thanks for your comment. What have you exactly in mind one tab for fixed and one tab for varying? And one group of tabs for stroke width and one for color? If not, can you point another part of QGIS that it is similar of what you think? |
-1 for tabs, it's more confusing that anything else and we've never used focused tab as a way to activate a state. The radio box isn't ideal but it's already a great improvement. You could use a combo box instead with nice icons to express what the mode does. That'd fit better with what we have elsewhere. Thanks for your flexibility so far, and for this great feature. |
I feel like the radio box provide a choice but not something that has ramification or would change the UI. Two radio button on a single line shouldn't change the rest of the section IMO. With the Tab this indicate that the underlying change is more involved and has more ramification. But it can also be seen as a concurrent thing rather than a choice between two option. Though I'm sure there is a way to not have the 'fixed' panel and integrate this in the other one. But otherwise as long as it works I don't mind. |
4d6e1b8
to
ef595c6
Compare
PR updated for symbol layer. @nirvn indeed, for fixed varying, combo box is better than radio button, for icons, it will be great to have the same as the preview icon in the layer tree but corresponding with fixed or varying. But maybe later... |
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.
Looking great, just minor bits before merging it...
} | ||
|
||
return colorRampShader; | ||
} |
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.
Hmm I am not a big fan of this implementation to read/write color ramp shader from/to QVariantMap:
- source color ramp properties are mixed with shader properties - can we keep them separated? (like it is done with "color_ramp_shader_items_list")
- source color ramp properies could be probably loaded/saved with QgsSymbolLayerUtils::colorRampToVariant() + QgsSymbolLayerUtils::loadColorRamp() - this would avoid the need to call create() method of various color ramp types directly
- legend settings are loaded/stored as embedded XML, which is suboptimal. And it looks like we do not need legend settings of the shader for interpolated line renderer anyway (though I understand you have added it for completeness)
I wonder if we could instead move these two functions as private methods to interpolated line symbol layer class... So it will be just implementation detail of the symbol layer, and not "official" API of QgsColorRampShader. By doing that, we could also afford to leave out the bits of information we don't need (like the mentioned legend settings). What do you think?
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.
done
@vcloarec |
This PR introduces a new
renderersymbol layer for line vector layers. This symbol layer is the porting of the mesh layer's edge rendering.The user can associate attributes or expressions to each line string's extremity (or curve). Value is interpolated along the line string between extremities.
The rendering is done with color and/or width
varying depending on the interpolated value, resulting in a color and width varying line.
The color rendering is set with a color ramp shader widget (like raster and mesh layers).
Funded by Lutra Consulting
Note: text above was changed following the discussion below.