[Qgis-developer] virtual fields

Sandro Santilli strk at keybit.net
Mon Mar 3 07:31:07 PST 2014


I also need this for TopoGeometry columns, in that often
TopoGeometry are referenced by "id" but no such attribute
as "id" exists.

In this case the expression would need to run in the database,
and the "virtual field" would be injected automatically rather
than being selected by the user.

--strk;

On Mon, Mar 03, 2014 at 03:16:11PM +0000, Andreas Neumann wrote:
> Hi Denis,
> 
> I proposed this a couple of years ago:
> http://osdir.com/ml/qgis-user-gis/2011-07/msg00313.html
> 
> But no-one dared to implement it until now.
> 
> Meanwhile the expressions are almost like "virtual columns" - but for
> some purposes it would still be good to have (e.g. in forms, for QGIS
> server outputting calculations, etc.). I can also see virtual columns
> that are aggregates of linked tables (e.g. the sum/min/max of linked
> records).
> 
> So I would also like to support such a development if someone wants to
> do the work.
> 
> Andreas
> 
> Am 03.03.2014 14:49, schrieb Denis Rouzaud:
> > Hi all,
> > 
> > I was wondering about the idea of being able to create simple views in
> > QGIS, "views" in terms of database.
> > Often, I use views (in postgres) to be able to create labels, title,
> > simple calculation or whatever and also to combine data from joined tables.
> > 
> > Somehow, all is already there in QGIS but in distinct features:
> > - joins which will add the fields of the joined table to the main table
> > - expressions are used in many places where views are meaningful:
> > labels, styling, search, etc.
> > - field calculation
> > 
> > I was thinking that these features should be grouped and improved in
> > what could be called virtual fields -- so basically a "live" field
> > calculation without writing to the provider.
> > 
> > First, the idea would be to define virtual fields using expressions.
> > 
> > Then, it should be made possible to integrate the joined fields in qgis
> > expressions without adding them to the current attributes (as it is now).
> > One way to to it could be a function: joinField( joinName, joinedFieldName)
> > Hence, the user would be allowed to choose which joined fields he really
> > wants to be accessible in the layer.
> > 
> > I believe this is a deep refactoring of the fields behavior, isn't it?
> > This could be a chance to clean up the joins, which I believe are a bit
> > messy now.
> > 
> > This is totally above my skills and somehow my available time, but I
> > would have (a part of) funding for this.
> > 
> > What do you think of this idea?
> > Would it be "easily"achievable without breaking the API?
> > Would you be interested in taking part of the dev?
> > 
> > Cheers,
> > 
> > Denis
> > 
> > 
> > 
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 

 ()  ASCII ribbon campaign  --  Keep it simple !
 /\  http://strk.keybit.net/rants/ascii_mails.txt  


More information about the Qgis-developer mailing list