#1162 closed bug (fixed)
missing possibility to use QML Style for more than one layer
Reported by: | bjpfei | Owned by: | jef |
---|---|---|---|
Priority: | critical: causes crash or data corruption | Milestone: | |
Component: | Project Loading / Saving | Version: | Trunk |
Keywords: | Cc: | cedric.moeri@… | |
Must Fix for Release: | Yes | Platform: | All |
Platform Version: | Awaiting user input: | no |
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?
Attachments (1)
Change History (19)
comment:1 by , 16 years ago
Must Fix for Release: | No → Yes |
---|---|
Priority: | major: does not work as expected → critical: causes crash or data corruption |
Type: | enhancement → bug |
follow-up: 3 comment:2 by , 16 years ago
Awaiting user input: | set |
---|
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
follow-up: 4 comment:3 by , 16 years ago
Replying to 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.
- Load a polygon layer with community borders.
- Create and save a unique values style QML based on community names.
- Load an other layer containing an attribute community names.
- Load the prior defined QML to the new layer.
- The legend name of the new layer is changed to the name of the first layer.
- Classification in map canvas is performed correctly but the legend is not updated.
- 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?
follow-up: 5 comment:4 by , 16 years ago
Replying to hdus:
Replying to 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.
- Load a polygon layer with community borders.
- Create and save a unique values style QML based on community names.
- Load an other layer containing an attribute community names.
- Load the prior defined QML to the new layer.
- The legend name of the new layer is changed to the name of the first layer.
- Classification in map canvas is performed correctly but the legend is not updated.
- 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.
comment:5 by , 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.
comment:6 by , 16 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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 r9438
comment:7 by , 15 years ago
Awaiting user input: | unset |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
the bugfix drops everything except the renderer information from the qml.
comment:8 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:10 by , 15 years ago
Component: | Symbology → Project Loading / Saving |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
It seems that the fix leeds to problems of reloading a project file.
- 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
- 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 r9746 all works fine, with r9747 the above mentined behaviour appears.
Loading shape works without problems.
follow-up: 14 comment:13 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
mmm... now loading of shape layers is broken.
follow-up: 15 comment:14 by , 15 years ago
Replying to hdus:
mmm... now loading of shape layers is broken.
hm. seems fine to me. what's the problem?
follow-up: 16 comment:15 by , 15 years ago
Replying to jef:
Replying to hdus:
mmm... now loading of shape layers is broken.
hm. seems fine to me. what's the problem?
I just compiled r9775 and all the problems of past r9746 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 r9746 and everything works fine.
My System: Qt 4.3.4 ReadHat AS4 PostgreSQL 8.3.3 PostGIS 1.3.3
comment:16 by , 15 years ago
Replying to hdus:
I just compiled r9775 and all the problems of past r9746 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.
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.:
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.