[Qgis-developer] Labeling: data-defined fields shifted after new vector API?

[Larry Shaffer]

Hi Andreas,

On Wed, Feb 6, 2013 at 5:45 AM, Andreas Neumann <a.neumann at carto.net> wrote:

> Hi,
>
> I changed the data-defined labeling in most of my projects - was a couple
> of hours of work. I would assume I am not the only one. Luckily, the
> cadastral map is just linked (embedded layers) and not duplicated.
>
> The more annoying thing is that QGIS crashes frequently because of these
> bad mappings. I had projects where QGIS crashed before I had an oppurtunity
> to fix the mapping. I went into the .qgs file, fixed it in the text editor
> and it was fine.
>
> So I would really appreciate if the data-defined labeling and symbology
> could use the column name instead of a numerical index. This way one could
> also more easily change the underlying tables should it be required.
>
> Thank you - Larry and Martin for fixing these issues!
>

Just a quick note to let you know I've committed work on this [0] and it
functions for my PostgreSQL/PostGIS project layers, as well as others.
Pre-2.0 projects should now open with data defined fields still correctly
mapped. I also implemented the field name-based properties for
QgsPalLabeling and updated several tools.

Please test with some of your pre-vector api project files and let me know
if you still get any crashes, or there are any data defined-related issues.
If so, please make a ticket and I'll work on it ASAP.

NOTE: Save As... when testing. Overwriting you older project files will
lead to loss of the old-style data defined properties (and their related,
though probably broken, field indices).

There may be some other labeling tools that need updated to work with the
new name-based properties or vector api. Along the way I noticed there are
now issues with the Unpin/Pin and Show/Hide label tools. Will work on those
next.

[0]
https://github.com/qgis/Quantum-GIS/commit/fbf999190cff378fb55b0ea7aadd2663f81d1828

Regards,

Larry


> Andreas
>
> On Wed, 6 Feb 2013 10:53:51 +0100, Martin Dobias wrote:
>
>> On Wed, Feb 6, 2013 at 10:20 AM, Larry Shaffer
>> <larrys at dakotacarto.com> wrote:
>>
>>> Thanks for the explanation. Figured it wouldn't be that simple. So, is it
>>> worth the effort to fix this (the 1.8 to 2.0 index issue)? I think many
>>> users will find manually updating their data defined mappings, for every
>>> layer in a project that has them, very annoying. This has the potential
>>> to
>>> become a very large time-sucking problem for many users.
>>>
>>
>> As far as I know, it should be a problem only in data-defined new
>> labeling - field names are used in other places.
>>
>>
>>  Could a lightweight QHash<old index, field name> be populated inline with
>>> the current building of the attribute vectors; only for those providers
>>> that
>>> would be different than before? The only-used-for-reads QHash could be
>>> used
>>> to create an auto-update routine for data defined mappings. Is something
>>> like that reasonable to implement? Is there another approach, or any at
>>> all?
>>>
>>
>> I think a real problem is there just with postgis layers - if I'm not
>> wrong, the holes in 1.x are appearing when geometry column is not at
>> the end of the list of fields, so for a layer with columns geom,
>> attr1, attr2 you would get attribute indices 1,2. As you can see,
>> implementing such mapping would be dependent on table structure. The
>> problem is that the stored indices get broken even with a change of
>> table structure - so even if we implemented some backward
>> compatibility for postgis (that would take table structure into
>> account), it might still cause problems.
>>
>> Martin
>> ______________________________**_________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
>>
>
> --
> --
> Andreas Neumann
> Böschacherstrasse 10A
> 8624 Grüt (Gossau ZH)
> Switzerland
> ______________________________**_________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer<http://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130207/edddea54/attachment.html>