Feature request #4123

"single symbol", "categorised" and "graduated" renderering should be removed as they are like subsets of "rule based" rendering

Added by Alister Hood over 13 years ago. Updated about 9 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Symbology
Pull Request or Patch supplied:No Resolution:invalid
Easy fix?:No Copied to github as #:14104

Description

- "single symbol", "categorised" and "graduated" symbology styles are unnecessary, because the same functionality is also provided by "rule-based" symbology.
- it is confusing having the same functionality available in two different ways.
- a user may spend a long time styling a large number of classes using graduated or categorised rendering, and then later find they need to categorise further using a second column, or need to use different symbology for different scales. If they switch to rule-based rendering they will need to style all the classes all over again.

I think the "single symbol, "categorised" and "graduated" renderers should be removed. It may also be necessary to make the rule-based renderer more user-friendly, e.g.
- add an error message for when the user clicks "Refine>Add [scales/categories/ranges]", with no rule selected.
- when opening the layer properties, select a rule by default.
- after editing a rule, keep it selected.
- after adding a rule, automatically select it.
- after removing a rule, automatically select the next rule.
- maybe, after adding scales/categories/ranges, automatically select the next rule (to make it easier to add them to several existing rules).
- possibly relabel or rearrange parts of the gui.

I guess removing "single symbol", "categorised" and "graduated" rendering would have implications for updating old projects, but I imagine now (i.e. for QGIS 2.0) would be the best time to do it.

mock_ups-rule_based_gui.jpg (707 KB) Alister Hood, 2011-08-02 01:51 AM

mock_ups-symbol___label_gui.jpg (694 KB) Alister Hood, 2011-08-02 02:08 AM

mock_ups.pdf (1.38 MB) Alister Hood, 2011-08-02 02:08 AM

History

#1 Updated by Alister Hood over 13 years ago

Another feature that would improve rule-based rendering would be a "clear rules" or "remove all" button.

Also:

- add an error message for when the user clicks "Refine>Add [scales/categories/ranges]", with no rule selected.

You might think it would be better to make it so that there is always a rule selected, like in the symbol layers dialogue.

#2 Updated by Alister Hood over 13 years ago

N.B. At least 2 features of the other renderers are currently missing in "rule based" rendering: the "Advanced" button for data-defined symbology, and "symbol levels".

#3 Updated by Martin Dobias over 13 years ago

I have to disagree. Single / categorized / graduated symbol renderers are choices what regular users would expect. Rule-based renderer is there for advanced users. Having just rule-based renderer must be an overkill for someone with just basic GIS knowledge. Apart from that rule-based renderer is slower than the other renderers because it has to evaluate expressions for each feature - other renderers are much faster from design.

I suggest you to either close the ticket or keep only the notes for improving the user friendliness of the rule-based renderer.

btw. I can imagine adding a feature that would convert an existing categorized / graduated renderer to rule-based renderer - so if you have spent a lot of time styling your layer the work would not have to be duplicated.

#4 Updated by Alister Hood over 13 years ago

  • File mock_ups.pdf added

Hi Martin,

I have to disagree. Single / categorized / graduated symbol renderers are choices what regular users would expect. Rule-based renderer is there for advanced users. Having just rule-based renderer must be an overkill for someone with just basic GIS knowledge.

1) I guess I'm trying to say that I think it would be possible to improve the gui for the rule-based renderer so that it is just as easy to use it instead of the separate renderers for simple "single", "categorized" or "graduated" rendering.

I am attaching a mockup of some ideas to try to achieve this, as well as a mockup of a possible single dialogue for symbol style and labelling (I think there has previously been some discussion about reducing the number of dialogues relating to symbology, and making them simpler). Someone else might be able to think of some more improvements, too.

2) I don't think that rule-based rendering should be a feature only for "advanced" users. I think that most "regular" users would want to do things like symbolise main highways differently from local roads in the same layer, and display the local roads only when zoomed in closer than 1:10,000. So it would be best to make the rule-based renderer as easy to use as possible... and removing the "simple", "categorized" and "graduated" renderers would make the gui (and I guess the code) simpler and less confusing.

Apart from that rule-based renderer is slower than the other renderers because it has to evaluate expressions for each feature - other renderers are much faster from design.

OK. Yes, I agree that speed is a significant issue.

But how much slower is it really when performing the same task? e.g. is rule-based rendering with one rule, "no filter", noticeably slower than single symbol rendering?

I could not measure any difference in speed, even when I compared single symbol rendering with rule-based rendering of 185 classes based on 37 categories and 5 scale ranges. Perhaps my layer wasn't big enough?

#5 Updated by Alister Hood over 13 years ago

jpeg versions of mockups

#6 Updated by Alister Hood over 13 years ago

  • File deleted (mock_ups.pdf)

#7 Updated by Alister Hood over 13 years ago

  • File deleted (mock_ups-symbol___label_gui.jpg)

#8 Updated by Alister Hood over 13 years ago

adding "diagrams" tab

#9 Updated by Alister Hood over 13 years ago

adding "diagrams" tab

#10 Updated by Alister Hood over 13 years ago

It probably isn't obvious: note that the dialogue I drew on in the second mockup is not an existing dialogue, it was made by combining features of the several existing dialogues that it would replace.

#11 Updated by Pirmin Kalberer about 12 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

#12 Updated by Nyall Dawson about 9 years ago

  • Resolution set to invalid
  • Status changed from Open to Closed

Closing due to lack of interest - I don't think there's any significant demand to rework these dialogs at the moment.

Also available in: Atom PDF