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

Martin Dobias wonder.sk at gmail.com
Wed Feb 6 01:53:51 PST 2013


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


More information about the Qgis-developer mailing list