[Qgis-developer] Labeling: data-defined fields shifted after new vector API?
Andreas Neumann
a.neumann at carto.net
Wed Feb 6 04:45:01 PST 2013
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
More information about the Qgis-developer
mailing list