<div dir="ltr">Hi Régis,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 1:07 PM, Régis Haubourg <span dir="ltr"><<a href="mailto:regis.haubourg@eau-adour-garonne.fr" target="_blank">regis.haubourg@eau-adour-garonne.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
I would like to explore the possibilities to extend EasyCustomLabeling to<br>
handle correctly curved labeling on lines, and maybe also labeling on the<br>
border of polygons.<br>
My idea is to make PAL engine compute curved labels, get label path and<br>
convert it to a linestring, a sort of label path.<br>
Is there any way in the python API to access label properties once computed<br>
by PAL? If not, does C++ API allows that?<br></blockquote><div><br></div><div>The label information available, after labeling is completed, is stored in QgsLabelPostion, used by the interactive labeling tools [0]. These are retrieved from a search tree via QgsLabelingEngineInterface's::labelsAtPosition(QgsPoint) and ::labelsWithinRect (QgsRectangle) [1]. All of that should already have bindings.<br>
<br></div><div>QgsLabelPostion has limited label component info, only the minimum needed for working with the interactive tools, e.g. just a bounding rectangle and corner points for geometries.<br><br>However, there are several outstanding bugs (and the advent of labeling styles) that could benefit from a new full label class that maintains as much information about the label *before* sending only the needed bits to PAL.  The label class properties would be resolved as needed to reduce overhead. This also means that if the registered label classes persist during PAL registration and solution, and rendering, then any new properties calculated along the way can be appended.<br>
<br></div><div>The stored result, accessed like QgsLabelPostion, could possibly contain all initial settings and resolved properties, as well as any geometries calculated during rendering, i.e. the "label path" you were referring to. It also means that additional lightweight geometries can be stored within it, like a data defined destination point for leader (call out) lines.<br>
</div><div><br></div><div>I have taken the next week off from my job to work solely on labeling issues. I'm pretty sure I will not have enough time to do such a large refactoring before the release, since squashing as many bugs as possible and finishing a full unit test suite should come first. <br>
</div><div><br></div><div>[0] <a href="http://www.qgis.org/api/classQgsLabelPosition.html">http://www.qgis.org/api/classQgsLabelPosition.html</a><br>[1] <a href="http://www.qgis.org/api/classQgsLabelingEngineInterface.html">http://www.qgis.org/api/classQgsLabelingEngineInterface.html</a><br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for your hints.<br>
Cheers<br>
Régis<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/Access-labels-properties-from-python-tp5101930.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/Access-labels-properties-from-python-tp5101930.html</a><br>

Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br></div></div></div>