Feature request #3488

Expression based labeling

Added by Nathan Woodrow over 3 years ago. Updated almost 3 years ago.

Status:Closed Start Date:
Priority:Low Due date:
Assigned to:Nathan Woodrow % Done:

90%

Category:Map Canvas
Target version:Version 2.0.0
Platform:All Resolution:fixed
Platform version: Patch supplied:No
Status info:0 Tag:

Description

There might be a trac already for this although I could not find it

It would be very handy to have expression based labels. This is something that I really miss coming from MapInfo as I tend to make labels that contain information from more than one column eg PipeSize + \n + PipeType

I know I can do this by adding a new column however that is limited to tables that I can edit. A lot of our tables are in MapInfo Tab format for just displaying purposes and because we still use MapInfo and it would be nice to have something that doesn't require a save to shape and table edit first. So the expression label feature should not need the table to be editable.

It would be good if it supported all the operations that the field calculator does eg + * / - and multiline

History

Updated by Mathieu Pellerin - nIRV over 3 years ago

That would indeed be very useful and a killer feature for QGIS' next version.

Other practical uses for expression based labeling:
- Nicer display of INT/FLOAT values (i.e. "$hectares + ' ha'")
- Ability to make basic string manipulation to further differentiate label types (lowercase(), uppercase(), capitalize(), etc.)

Updated by Nathan Woodrow over 3 years ago

  • Assigned to changed from J├╝rgen Fischer to Nathan Woodrow
  • Target version changed from Version 1.7.0 to Version 2.0.0
  • % Done changed from 0 to 30

I have started working on this feature in a branch on my github repo (https://github.com/madmanwoo/Quantum-GIS/tree/expression-labels)

The expression based labeling works, I'm just working on a new dialog to build the expression string. The dialog would be something like the field calculator. The field calculator is coded only for the attribute table at the moment to be reused in this situation.

I have exams in two weeks but well continue work on it after that.

Updated by Alister Hood over 3 years ago

Does that branch still exist somewhere, Nathan?

Updated by Nathan Woodrow over 3 years ago

Opps yeah it does; I changed my github username it's now here: https://github.com/NathanW2/Quantum-GIS/tree/expression-labels

Updated by Nathan Woodrow over 3 years ago

This is what I have done so far with the dialog.

The expression based labeling works I'm just cleaning up the UI and the code in order to send a patch.

Updated by Borys Jurgiel over 3 years ago

Please note also #4080. I think this one, #3843 and #4080 should be considered in somehow consistent way.
There is also #1419

Updated by Aren Cambre about 3 years ago

  • Patch supplied set to No

I just marked #1419 as duplicate of this issue. I think this issue is an elegant, generic solution that will fix #1419.

(Um, just noticed this system says I set "Patch supplied" to "No". I didn't do that, and not sure why it said I did.)

Updated by Mathieu Pellerin - nIRV about 3 years ago

/me salivates thinking qgis is close to get expression based labeling

Nathan, are you planning to add basic functions to manipulate strings / numbers? In no particular order, I'm thinking:
- uppercase(string)
- lowercase(string)
- capitalize(string)
- number_format(number, decimal_char, thousands_char).

Updated by Nathan Woodrow about 3 years ago

Sure adding those kinds of things should be pretty easy, it's mainly just a matter of adding them to the QgsExpression class. Martin ala wonder-sk is the guy that can add that stuff in pretty easily as he just redesigned the expression parser.

I think the goal is to have as close to SQL syntax as possible, so we would use UPPER.
I would open another ticket if you want to get that stuff added in.

Updated by Nathan Woodrow about 3 years ago

  • % Done changed from 30 to 60

Also just a update on this addition. Over the weekend I merged in Martins recent updates, in a separate branch to the github one, into my branch to update it to use the new expression parser. Once I have tested it with the new expression parser and made sure it's still stable I will update the github branch. The main thing that is left to do is work on the UI from the screenshot above and code clean up.

Updated by Martin Dobias about 3 years ago

nirvn - wrote:

/me salivates thinking qgis is close to get expression based labeling

Nathan, are you planning to add basic functions to manipulate strings / numbers? In no particular order, I'm thinking: - uppercase(string) - lowercase(string) - capitalize(string) - number_format(number, decimal_char, thousands_char).

FYI: there are already upper(string) and lower(string). For capitalization it seems that initcap(string) is the usual choice for the function name (postgresql, oracle, ms sql). For number formatting I do not know if there is any standard, but keep in mind that some people also would like to specify the number of digits before/after decimal point and optionally add some padding (with zeros or spaces).

Updated by Martin Dobias about 3 years ago

Nathan Woodrow wrote:

This is what I have done so far with the dialog.

The expression based labeling works I'm just cleaning up the UI and the code in order to send a patch.

Nathan, just wondering - is that a completely new dialog? Because currently we have a similar dialog for field calculator (qgsfieldcalculatorbase.ui) and for query builder (qgsquerybuilderbase.ui). This is already suboptimal, so a new dialog should be avoided.

Ideally we should have a reusable widget that provides the text area, list of operators / functions with help, and maybe a way how to get a sample (or all values) from a selected column. Such a widget would be then embedded into all the dialogs that do something with expressions.

Updated by Nathan Woodrow about 3 years ago

Yeah it is a new dialog however it is implemented as a reusable Widget with the intention to use it any where that needs expressions eg QueryBuilder and Field Calculator.

I was going to use the existing ones but they both didn't really serve a generic solution that could be adapted into any situation; they also weren't every expandable with the growing list of functions.

So yes my overall goal with the widget is to replace the others, remove some code logic duplication and create a more uniformed UI.

Thoughts?

Updated by Martin Dobias about 3 years ago

Ok, that makes sense: to develop a new reusable widget and then use it also for the field calculator and search query builder.

I think you have a good directions, a big grid of buttons with all the operators and functions is not sustainable. Have you done some research how such editor looks in other software? Doing a google image search for "expression editor" yields quite a lot of examples. It would be good to compare them and identify the good, the bad and the ugly ones.

Updated by Anita Graser about 3 years ago

Would it be possible to implement a "substring" operator too? That way, users could reformat date strings from "YYYY-mm-dd" to "dd.mm.YYYY" for example.

Updated by Martin Dobias about 3 years ago

Anita, "substring" operator is there, too. The syntax is substr(text, from, len) where "from" is indexed from one.

Updated by Nathan Woodrow about 3 years ago

  • % Done changed from 60 to 90

Pull request made https://github.com/qgis/Quantum-GIS/pull/51

Still a few things to add later on but if it could be added to master for wider testing that would be good :)

Updated by Alister Hood about 3 years ago

Can I suggest a discussion/brainstorm on the UI?
I can imagine that with the full list of operators and a large number of fields it could become annoying scrolling up and down repeatedly. It might be slightly better to put Operators, Geometry and Fields on different tabs or something.

Updated by Nathan Woodrow about 3 years ago

There is a real time search at the top that limits the entries to show only stuff with that keyword.

The tab idea is interesting although I worry that you run into a problem of when do you stop making new tabs for lists, the other lists could, in future, get just as big. I added to the search to reduce this problem.

Martin, your thoughts?

Updated by Martin Dobias about 3 years ago

I am also in favor of keeping the current design. Further improvements may be added later if needed.

Updated by Martin Dobias about 3 years ago

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

The pull request merged. Good work, Nathan!

Updated by Mathieu Pellerin - nIRV about 3 years ago

Nathan, thanks a gazillion times for this.

Updated by Mathieu Pellerin - nIRV about 3 years ago

Nathan, IMO a capitalize('string') function would be really, really useful alongside uppercase / lowercase.

Updated by Nathan Woodrow almost 3 years ago

nirvn, no worries, Hopefully people find it useful. I would open a ticket if you want some other functions added.

Martin, thanks for the merge :).

Updated by Mathieu Pellerin - nIRV almost 3 years ago

Nathan, good idea.

Bug #4425: capitalize() function
Bug #4426: number_format() function

Cheers.

Also available in: Atom PDF