Bug report #1162

missing possibility to use QML Style for more than one layer

Added by bjpfei - over 16 years ago. Updated over 15 years ago.

Status:Closed
Priority:Low
Assignee:Jürgen Fischer
Category:Project Loading/Saving
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11222

Description

In the qml-File informations about datasource or layername are stored.

<datasource>dbname='bla' host=localhost port=123 user='test' table="zonenplan"."grundnutzung" (wkb_geometry) sql=</datasource>
    <layername>grundnutzung</layername>

Furthermore the classificationfield is stored as column-number and not with the fieldname. 
<classificationfield>13</classificationfield>

Thus at the moment it's not possible to use a QML-Style for more than one layer. If you use it with another layer QGIS renders nothing or in some cases still crashes.
However I think the sense of a QML-Style is using it for more than one layer because for use with one layer we have the standard style.
So, are there any reasons for saving all these informations in the QML-Style?

bugfix_ticket1162.diff.bz2 - This will resolve the issue. (9.93 KB) Tim Sutton, 2008-10-06 05:53 AM

Associated revisions

Revision 118b2158
Added by Jürgen Fischer almost 16 years ago

fix #1162

git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@9771 c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 56b5ba7e
Added by Jürgen Fischer almost 16 years ago

fix #1162

git-svn-id: http://svn.osgeo.org/qgis/trunk@9771 c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Maciej Sieczka - over 16 years ago

I don't consider this issue as an enhacement request. It is a critical bug rather. If re-using QMLs for different layers is not supported, QGIS should explicitely prevent it. Otherwise user's project becomes corrupted. E.g.:

1. Set up symbology for a shapefile.

2. Save the style for this shapefile.

3. Load it for another Shapefile.

The 'another' shapefile is now replaced by the Shapefile for which the symbology was set-up for in 1. A couple of weird, random issues begin to crop out - can't remove some layers in the project, saving and reloading the project sometimes make some layers dissapear etc.

#2 Updated by Tim Sutton about 16 years ago

Can you confirm if this bug is still an issue using svn trunk? For me it works fine in svn trunk.

Regarding the field number instead of field name issue, you should file a separate bug for that since its a 'feature' of how layer properties are serialised - qml files make use of the standard QGIS serialisation routines to do their thing.

Regards

Tim

#3 Updated by Horst Düster about 16 years ago

Replying to [comment:2 timlinux]:

Can you confirm if this bug is still an issue using svn trunk? For me it works fine in svn trunk.

Regarding the field number instead of field name issue, you should file a separate bug for that since its a 'feature' of how layer properties are serialised - qml files make use of the standard QGIS serialisation routines to do their thing.

Regards

Tim

The fix looks to be half done.

1. Load a polygon layer with community borders.

2. Create and save a unique values style QML based on community names.

3. Load an other layer containing an attribute community names.

4. Load the prior defined QML to the new layer.

5. The legend name of the new layer is changed to the name of the first layer.

6. Classification in map canvas is performed correctly but the legend is not updated.

7. Toggle the visibility of the new layer off and on, the layer disappears from map canvas.

What could be a way to handle this issue? Perhaps a solution could be as follows:

When I load a QML Style to a layer QGIS have to check whether this QML is associated to the layer or not. This information is known from the connection parameters. If the layer is not associated don't change the layer name and ask the user to choose an appropriate attribute of the given attributes. The user is responsible for the correctness of the choosen attribute. Maybe this could be an appropriate approach?

#4 Updated by Ollie O'Brien - about 16 years ago

Replying to [comment:3 hdus]:

Replying to [comment:2 timlinux]:

Can you confirm if this bug is still an issue using svn trunk? For me it works fine in svn trunk.

Regarding the field number instead of field name issue, you should file a separate bug for that since its a 'feature' of how layer properties are serialised - qml files make use of the standard QGIS serialisation routines to do their thing.

Regards

Tim

The fix looks to be half done.

1. Load a polygon layer with community borders.

2. Create and save a unique values style QML based on community names.

3. Load an other layer containing an attribute community names.

4. Load the prior defined QML to the new layer.

5. The legend name of the new layer is changed to the name of the first layer.

6. Classification in map canvas is performed correctly but the legend is not updated.

7. Toggle the visibility of the new layer off and on, the layer disappears from map canvas.

What could be a way to handle this issue? Perhaps a solution could be as follows:

When I load a QML Style to a layer QGIS have to check whether this QML is associated to the layer or not. This information is known from the connection parameters. If the layer is not associated don't change the layer name and ask the user to choose an appropriate attribute of the given attributes. The user is responsible for the correctness of the choosen attribute. Maybe this could be an appropriate approach?

Just to add a "Me too", I can confirm that this is indeed the case - applying a QML style file to a different layer does now work - but as soon as the layer (or any other layer) is toggled off/on, all the layers using QML style files that weren't originally created for them disappear from the canvas, apparently permanently.

In point 5, I think the reason for this is that the display name (for the legend) defaults to the layer name and this gets saved down with the QML style file creation - so gets reapplied to a different layer. This feels to me like "functioning as intended" - I would actually want the layer name to be picked up from the QML, for my legend.

#5 Updated by Ollie O'Brien - about 16 years ago

On point 7 - the layers concerned (those with QML files from other layers) also disappear if a new (unrelated) layer is added to the canvas.

#6 Updated by Tim Sutton about 16 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

This issue is fixed at QGIS code sprint Warmwaterberg just near Ronnies Sexshop ;-) coords 20.900,-33.765 by Tim, Marco (really mostly), Horst and Till. (Mission completed) Fixed with b4937cb8 (SVN r9439)

#7 Updated by Jürgen Fischer almost 16 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (fixed)

the bugfix drops everything except the renderer information from the qml.

#8 Updated by Jürgen Fischer almost 16 years ago

  • Status changed from Feedback to Open

#9 Updated by Jürgen Fischer almost 16 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

fixed in 270fe71f (SVN r9748)

#10 Updated by Horst Düster almost 16 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (fixed)

It seems that the fix leeds to problems of reloading a project file.

1. Issue: I load a vector layer via Python plugin from PostGIS without QML symbology. The layer is loaded correct. Save project and reload project, QGIS throws an error message: unable to load layer

2. Issue: I load a vector layer via PostGIS connector without QML symbology. The layer is loaded correct. Save project and reload project, QGIS doesn't throw an error the layer is loaded but not displayed.

With e7f90b4d (SVN r9747) all works fine, with 270fe71f (SVN r9748) the above mentined behaviour appears.

Loading shape works without problems.

#11 Updated by Jürgen Fischer almost 16 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed

fixed in 56b5ba7e (SVN r9772)

#12 Updated by Horst Düster almost 16 years ago

Jürgen, thank you very much for the fix

#13 Updated by Horst Düster almost 16 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (fixed)

mmm... now loading of shape layers is broken.

#14 Updated by Jürgen Fischer almost 16 years ago

Replying to [comment:13 hdus]:

mmm... now loading of shape layers is broken.

hm. seems fine to me. what's the problem?

#15 Updated by Horst Düster almost 16 years ago

Replying to [comment:14 jef]:

Replying to [comment:13 hdus]:

mmm... now loading of shape layers is broken.

hm. seems fine to me. what's the problem?

I just compiled c861e6c2 (SVN r9776) and all the problems of past e7f90b4d (SVN r9747) still appears :-((

Now I get an additional problem. I'm not able to save QML-Files from PostGIS Layers via the "save style ..." button. QGIS Throws an error:

"Could not save symbology because:"

Thats all, no reason is mentioned. QML for Shape-Files are saveable without any problems.

I recompile e7f90b4d (SVN r9747) and everything works fine.

My System:
Qt 4.3.4
ReadHat AS4
PostgreSQL 8.3.3
PostGIS 1.3.3

#16 Updated by Jürgen Fischer almost 16 years ago

Replying to [comment:15 hdus]:

I just compiled c861e6c2 (SVN r9776) and all the problems of past e7f90b4d (SVN r9747) still appears :-((

Now I get an additional problem. I'm not able to save QML-Files from PostGIS Layers via the "save style ..." button. QGIS Throws an error:

"Could not save symbology because:"

Strange. I can't reproduce any of this.

#17 Updated by Jürgen Fischer almost 16 years ago

  • Resolution set to fixed
  • Status changed from Feedback to Closed

fixed in

#18 Updated by Anonymous over 15 years ago

Milestone Version 1.0.0 deleted

Also available in: Atom PDF