[Qgis-developer] Bringing diagrams into labeling-ng

[Marco Hugentobler]

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
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee