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

[Andreas Neumann]

 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!

 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

-- 
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland