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
<lar...@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
