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

[Larry Shaffer]

Hi Martin,

On Wed, Feb 6, 2013 at 2:53 AM, Martin Dobias <wonder.sk at gmail.com> 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.
>

Yes, definitely they should be moved to field-name-based data defined
mappings. Even doing that, though, will require a means of auto-conversion
(like with api change) to properly map the old index value to its field
name, only once, to migrate over.

> 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.
>

I understand, as this is the case with most of the labeled layers in my
PostGIS projects. Many are created from shapefile imports, then the
specialized labeling fields are added. Geometry column is basically never
the last one. All of those layers are at least partially messed up, data
defined-wise.

My thoughts are to use that QHash in
QgsPalLayerSettings::_readDataDefinedProperty to convert the stored field
index property to its field name when the value is found to be an integer
(indicating old-style index stored). I would also be saving the new field
name mapping in a different property built off of the enum's literal string
value, e.g.

key="/labeling/dataDefined/Bold" value="label_bold"
  instead of
key="labeling/dataDefinedProperty1" value="9"

erasing the old index-based property on successful write of the new one. If
the QHash is empty, then the current stored index value can be 'trusted' to
map to the proper field name, i.e. provider never had holes to begin with.
Does that make sense to you? Any ideas on adding such a backward
compatibility QHash to the base data provider and implement it in just the
postgres provider (unless there are others that had QMap hole issues)?

Of course, regardless of adding an auto-conversion, if the user adjusts the
table structure before the conversion is done there will be messed up field
mappings, just like before. Since the conversion should only happen once on
the first opening of the <2.0 project file (only time the QHash is used),
there is a high likelihood the auto-conversion will transparently work with
no issues. Then, the QHash fix can be deprecated sometime in the future.

Also, moving to field name-based data defined mappings should allow join
tables to function better for such mappings.

Regards,

Larry


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