Feature request #6325
Add PAL labelling features for Python access
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Labelling | ||
Pull Request or Patch supplied: | No | Resolution: | worksforme |
Easy fix?: | No | Copied to github as #: | 15612 |
Description
The new PAL Labelling system looks to be superseding the old one (now shown as deprecated under Layer Properties). Could the public (accessed via GUI) features please be made available for Python programming.
I want to programatically set labels and other attributes from the Python code so the user gets a nice looking layer without needing to change the layer properties themselves. Being able to set features available under the new labelling engine (also available on the Toolbar would be useful), such as (not) "Label every part of a multi-part feature" and avoiding label collisions. Also the look of the labels generated using the latter method are usually better. If this is to become the default labelling system, then it would be good to be able to recreate the look/feel via Python.
History
#1 Updated by Ian Packham about 12 years ago
Sorry, I have created this issue under the wrong category - should be under "Labelling". I cannot change the category. Please amend or, if you prefer, delete this issue and I will recreate it in the right place.
#2 Updated by Paolo Cavallini about 12 years ago
- Project changed from 27 to QGIS Application
#3 Updated by Paolo Cavallini about 12 years ago
- Category set to Labelling
#4 Updated by Larry Shaffer about 12 years ago
See also, for background: http://gis.stackexchange.com/questions/32847
#5 Updated by Larry Shaffer about 12 years ago
- Resolution set to worksforme
- Status changed from Open to Feedback
- Target version set to Version 2.0.0
Ian,
Jürgen added the Python bindings with commit d8675ba3 (and follow up commit)
Please test. I have tested with setting PAL layer options (followed by canvas refresh) and seems to work well.
#6 Updated by Ian Packham about 12 years ago
That was fast, thank you.
Would this commit be included in the qgis-dev nightly builds of the master (available in the OsGeo4W-setup for Windows Installer)? I have installed the latest (v1.9.0-66), but when I go to Python Console, I get this error:
Failed to open Python console: exceptions.ImportError: No module named Qsci
I also added the qscintilla package under Libs, but this didn't help.
I am a newbie at testing code from dev. From the commit link I can't work out which methods etc are now available in Python. Is there somewhere else I should look as well for documentation?
#7 Updated by Jürgen Fischer about 12 years ago
Ian Packham wrote:
I also added the qscintilla package under Libs, but this didn't help.
Try python-qscintilla.
From the commit link I can't work out which methods etc are now available in Python.
I missed the new file in the first commit - that's why Larry mentioned the follow up commit (8898e6b847) which has qgspallabeling.sip.
#8 Updated by Ian Packham about 12 years ago
Sorry, I was looking for it, but I missed your missed commit file. Got the build working OK with python-qscintilla.
Managed to set some attributes of PAL from python, although not tested everything. Setting palyr.labelPerPart = True
did not change the labels in a polygon layer, but I also cannot change it via the PalLabelling toolbar and clicking the checkbox. so maybe something else is missing in the underlying code?
I like that this setting is labelPerPart feature is False by default, by the way; in fact I probably don't want to change much for these settings, just being able to switch this PalLabelling on programmatically is very useful.
#9 Updated by Larry Shaffer about 12 years ago
Ian Packham wrote:
Managed to set some attributes of PAL from python, although not tested everything. Setting
palyr.labelPerPart = True
did not change the labels in a polygon layer, but I also cannot change it via the PalLabelling toolbar and clicking the checkbox. so maybe something else is missing in the underlying code?
The labelPerPart property refers to features that have multiple parts; so, you wouldn't see any changes to your labeling if the features of the layer (that are valid, visible and being labeled) do not have multiple parts. It's fairly common to have line layers, e.g. roads, with multiple parts per feature.
#10 Updated by Ian Packham about 12 years ago
Larry
The layer I was testing is a MultiPolygon, some of the features have multiple parts, it is a postgres layer and ST_IsValid returns true for the features in question. Loading the same layer in v1.8.0 and checking the "Label every part of multi-part features" checkbox, I get the same label on more than 1 part of the feature. Using the same layer in the dev build and checking the box in the same way, does not change the labelling.
#11 Updated by Larry Shaffer about 12 years ago
Hi Ian,
Sounds like a bug that may have been caused by some recent code I've added. Please create a new issue (bug) ticket and assign it to me. If you can, provide a sample of your data set that includes single and multi-part features. Also describe which placement options you were using. I suspect the multi-part option does work, but not for the Offset and Around placements. I will look into this ASAP.
Thank you for reporting the issue.
If you have tested the new Python bindings, and they seem to work well, consider closing this issue, if you have the permission to do so; or, I can.
#12 Updated by Ian Packham about 12 years ago
New issue created: #6378. I don't have permissions to close an issue - yet?
#13 Updated by Larry Shaffer about 12 years ago
- Status changed from Feedback to Closed