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

[Larry Shaffer]

Hi Martin,

On Wed, Feb 6, 2013 at 1:17 AM, Martin Dobias <wonder.sk at gmail.com> wrote:

> Hi Larry
>
> On Wed, Feb 6, 2013 at 4:25 AM, Larry Shaffer <larrys at dakotacarto.com>
> wrote:
> > Is mFields[i].originIndex (where mFields is a QgsFields vector) the same
> > index used for the keys in QgsFieldMap?
>
> No, it's not the same thing. "originIndex" is a mapping from layer's
> attribute indices to provider's indices. That's needed when one or
> more fields have been removed in layer's editing mode (and also used
> for identification of joined attributes). For example, if you have a
> layer with attributes attr1, attr2, attr3 and you decide to delete
> attr2, the index of attr3 will change from 2 to 1, but the originIndex
> will stay the same. Before new API merge, if an attribute was deleted
> in editing mode, indices would not change (because holes were
> allowed).
>
>
> > In other words, will this new method, QgsFields::toQgsFieldMap(),
> function
> > correctly [0]? If so, I can use it to attempt to auto-convert
> > QgsFieldMap-index-based data defined properties over to field-name-based
> > properties, without having think about reintroducing any QgsFieldMap
> > functionality at the provider level.
>
> That wouldn't help, because the numbering of fields has been changed
> on provider level (e.g. a provider used to return indices 0,1,3, now
> it returns 0,1,2), so I am afraid there's no simple way to establish
> mapping of attribute indices from old API providers to new API
> providers (because some have changed, others haven't).
>

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.

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?

Regards,

Larry


> Regards
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130206/18cb84dc/attachment.html>