Hi Alister > Perhaps I'm missing something, but it seems to me that a much better > solution would be to enable editing of joined tables in the table joins > branch. > Instead of being saved in the project file, label information could then > be saved in a joined table. This would have the following advantages: > > - The project file would not become bloated with label information > - Label information could be easily reused between projects > - The work done to implement it would benefit not only labelling, but > also other uses of writable table joins. > > > I also guess that it might result in less of an increase in code > complexity, and therefore be less of a burden for code maintenance... > but I could well be wrong about this :)
Yes, true. In fact, in many cases where the data defined labeling positions are in use, it comes from db tables joined by a view. The code of the table join branch is in trunk now, but without editing possibility for joined fields (unfortunately even without indication that joined fields cannot be edited). I agree it makes sense to enable editing for joined fields too. Regarding the question of storing label / diagram positions in attributes or in project file: there are good use cases for both and one does not exclude the other. While storing in attributes is already implemented, it would be good to have in future a user option to select wether to load/store in data columns or in project file. Btw., I'm progressing with the diagrams, so hopefully I can publish a patch soon. Regards, Marco Am Dienstag, 1. März 2011, 23.26:27 schrieb Alister Hood: > Hi everyone, > > I somehow sent this to the old sourceforge list by mistake :( > > I'm not a developer, but I saw this: > >>> it would be nice to be able to > >>> > >>>interactively place the diagrams as you have done with labels. How > >>> > >>>would the diagram's placement be persisted? In the same way as labels > >>> > >>> > >>>using a specified columns? Some users have requested that label > >>> > >>>placement could work like E$RI where the labels can be turned into > >>> > >>>graphics and placement is stored in the project file (or whatever the > >>> > >>> > >>>ESRI equivalent of that is) - so that you don't > >>> > >> The placement would be the same as for labels (stored in columns). > >> > >> The option to change the objects to graphics would be nice. > >> > >> Technically, it could probably be done by turning the labels into > >> > >> annotation objects (QgsTextAnnotation). However, this is out of scope > > for me at the moment. > > >I think the labels/diagrams do not have to be converted to graphics, > > > >since that might complicate their connection with the layer and the > > > >automatic placement (e.g. if the label text field is modified or the > > > >placement should be recalculated because of changes in the layer). > > > > > > > >I share Tim's opinion opinion that in future it would be good to allow > > > >to save the placement in project file (or maybe an independent file). > > > >While keeping the placement information in layer attributes might be > > > >convenient for some (as commented in follow up mail from Andreas), it > > > >has some difficulties, too: > > > >- if a layer is used in various independent projects, the labeling > > > >requirements might be different for each of them > > > >- it's not very user friendly if the users need to manually add new > > > >attributes to the layer, assign them to labeling and learn what values > > > >to put there > > > >- the approach using attributes is not that flexible: things like > > > >curved labels or any custom labeling properties would be rather hard to > > > > > >represent in layer's attributes > > Perhaps I'm missing something, but it seems to me that a much better > > solution would be to enable editing of joined tables in the table joins > > branch. > > Instead of being saved in the project file, label information could then > > > be saved in a joined table. This would have the following advantages: > > > > - The project file would not become bloated with label information > > - Label information could be easily reused between projects > > - The work done to implement it would benefit not only labelling, but > > also other uses of writable table joins. > > > > I also guess that it might result in less of an increase in code > > complexity, and therefore be less of a burden for code maintenance... > > but I could well be wrong about this :) > > > > Regards, > > Alister -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland [email protected] http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
