<div dir="ltr">Hi Andreas,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 5:45 AM, Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thank you - Larry and Martin for fixing these issues!<br></blockquote><div><br></div><div>Just a quick note to let you know I've committed work on this [0] and it functions for my PostgreSQL/PostGIS project layers, as well as others. Pre-2.0 projects should now open with data defined fields still correctly mapped. I also implemented the field name-based properties for QgsPalLabeling and updated several tools.<br>
</div><div><br></div><div>Please test with some of your pre-vector api project files and let me know if you still get any crashes, or there are any data defined-related issues. If so, please make a ticket and I'll work on it ASAP.<br>
<br></div><div>NOTE: Save As... when testing. Overwriting you older project files will lead to loss of the old-style data defined properties (and their related, though probably broken, field indices).<br></div><div><br></div>
<div>There may be some other labeling tools that need updated to work with the new name-based properties or vector api. Along the way I noticed there are now issues with the Unpin/Pin and Show/Hide label tools. Will work on those next.<br>
<br>[0] <a href="https://github.com/qgis/Quantum-GIS/commit/fbf999190cff378fb55b0ea7aadd2663f81d1828">https://github.com/qgis/Quantum-GIS/commit/fbf999190cff378fb55b0ea7aadd2663f81d1828</a><br><br></div><div>Regards,<br></div>
<div><br></div><div>Larry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Andreas<br>
<br>
On Wed, 6 Feb 2013 10:53:51 +0100, Martin Dobias wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Feb 6, 2013 at 10:20 AM, Larry Shaffer<br>
<<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for the explanation. Figured it wouldn't be that simple. So, is it<br>
worth the effort to fix this (the 1.8 to 2.0 index issue)? I think many<br>
users will find manually updating their data defined mappings, for every<br>
layer in a project that has them, very annoying. This has the potential to<br>
become a very large time-sucking problem for many users.<br>
</blockquote>
<br>
As far as I know, it should be a problem only in data-defined new<br>
labeling - field names are used in other places.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Could a lightweight QHash<old index, field name> be populated inline with<br>
the current building of the attribute vectors; only for those providers that<br>
would be different than before? The only-used-for-reads QHash could be used<br>
to create an auto-update routine for data defined mappings. Is something<br>
like that reasonable to implement? Is there another approach, or any at all?<br>
</blockquote>
<br>
I think a real problem is there just with postgis layers - if I'm not<br>
wrong, the holes in 1.x are appearing when geometry column is not at<br>
the end of the list of fields, so for a layer with columns geom,<br>
attr1, attr2 you would get attribute indices 1,2. As you can see,<br>
implementing such mapping would be dependent on table structure. The<br>
problem is that the stored indices get broken even with a change of<br>
table structure - so even if we implemented some backward<br>
compatibility for postgis (that would take table structure into<br>
account), it might still cause problems.<br>
<br>
Martin<br>
______________________________<u></u>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>developer</a><span><font color="#888888"><br>
</font></span></blockquote><span><font color="#888888">
<br>
-- <br>
--<br>
Andreas Neumann<br>
Böschacherstrasse 10A<br>
8624 Grüt (Gossau ZH)<br>
Switzerland<br>
______________________________<u></u>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>developer</a><br>
</font></span></blockquote></div><br></div></div></div>