<div dir="ltr">Hi Martin,<br><br><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 6, 2013 at 3:38 AM, Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</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"><div dir="ltr">Hi Martin,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 2:53 AM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</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">On Wed, Feb 6, 2013 at 10:20 AM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>> wrote:<br>
> 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>
<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></blockquote><div><br></div><div>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.<br>
</div><div><br></div><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>
<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.<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.<br>
<br>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.<br>
<br></div><div>key="/labeling/dataDefined/Bold" value="label_bold"<br></div><div> instead of<br>key="labeling/dataDefinedProperty1" value="9"</div><div><br></div><div>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)?<br>
</div></div></div></div></div></blockquote><div><br></div><div>I implemented this in a very simple manner in a feature branch [0], which is also available as a patch [1]. Using the following in PyQGIS console, with a PostGIS layer selected:<br>
<br>pv = iface.activeLayer().dataProvider()<br>pv.palAttributeIndexNames()<br><br></div><div>returns for my test layer...<br><br>{0: PyQt4.QtCore.QString(u'id'),<br>2: PyQt4.QtCore.QString(u'Label_Text'),<br>
3: PyQt4.QtCore.QString(u'Label_FontSize') ... }<br><br></div><div>which matches previous index-to-name mapping (geom column is index #1) and can be used to fix the issue with QgsPalLabeling, make an auto-updating function, and move to field name mappings. If run on a layer not PostGIS, it returns an empty QHash, implying the fix is not needed for the provider.<br>
</div><div><br></div><div>However, I don't want to mess with data providers without sound advice from those in the know. :^) Please let me know if such an approach is a reasonable solution, I'm missing something, or you have a better idea.<br>
</div><div><br>[0] <a href="https://github.com/dakcarto/Quantum-GIS/tree/labeling_vector-api-fix_1">https://github.com/dakcarto/Quantum-GIS/tree/labeling_vector-api-fix_1</a> ,<br><a href="https://github.com/dakcarto/Quantum-GIS/commit/a8bda0575db5783f53f44054a3a522953c9ffbcf">https://github.com/dakcarto/Quantum-GIS/commit/a8bda0575db5783f53f44054a3a522953c9ffbcf</a><br>
[1] <a href="http://drive.dakotacarto.com/qgis/qgsdataprovider-qgspallabeling_patch.diff">http://drive.dakotacarto.com/qgis/qgsdataprovider-qgspallabeling_patch.diff</a><br><br></div><div>Regards, and thanks for your help,<br>
<br></div><div>Larry<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">
<div></div><div>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.<br>
<br></div><div>Also, moving to field name-based data defined mappings should allow join tables to function better for such mappings.<br></div><div><br></div><div>Regards,<br><br></div><div>Larry<br><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><font color="#888888">
Martin<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>