[Qgis-developer] Table join branch

[John C. Tull]

Hi Marco,

This sounds like another great addition on your part. Is, or will there be, a means to export a joined layer to a vector format that creates an attribute table with both the original layer table and the joined table? In other words, will an export of a join result in a new layer complete with both attribute tables?

Thanks,
John

On Jul 19, 2010, at 12:10 AM, Marco Hugentobler wrote:

> Hi QGIS devs
> 
> There is now the table_join_branch (svn co 
> https://svn.osgeo.org/qgis/branches/table_join_branch) which contains an 
> initial table join prototype. Here is a short description how to use it:
> - Load a vector layer
> - Load a table layer. This can be done e.g. using 'Layer->Add Vector Layer...' 
> on a .dbf or .csv file
> - Go to vector layer properties->join and click '+' to add a new join
> - Select join field of table and join-to field of vector layer
> - Now you should see the new fields in the attribute tab of the vector layer 
> properties, in the attribute table and in the info-tool window
> 
> Internally, QgsVectorLayer stores the join info (fields and join table provider 
> key) and remaps the field ids (first the provider ids, then the joined field ids 
> and last the added field ids). When querying the joined field values, a subset 
> string is set to the table provider to query a feature with the value of the 
> join field.
> 
> As you might expect, there are still a number of issues:
> - Joined fields cannot be edited (should they?). So attribute table and info-
> tool should disable those rows. QgsVectorLayer probably needs a method to tell 
> attribute table and info tool which rows are not editable.
> - Performance is an issue. The current implementation tries to improve 
> performance by automatically creating attribute indices in the ogr provider 
> (could be implemented in other providers too). Still there is a siginificant 
> performance penalty when doing classifications based on joined attributes or 
> attributes searches (info tool and opening attribute table are usually fast, 
> because not many features are queried at once).
> One possibility to enhance this could be to load tables into memory providers 
> and implementing attribute index capability there. Are there other 
> possibilities?
> 
> Looking forward to you feedback and suggestions. I'm sure there are a lot of 
> issues I didn't consider.
> 
> @Martin: in your gsoc blog, you write that you are refactoring the editing 
> buffer to a utility class. Do you think the join info and the id remaping can 
> be ported to the new design easily?
> 
> Regards,
> Marco
> 
> 
> -- 
> Dr. Marco Hugentobler
> Sourcepole - Linux & Open Source Solutions
> Webereistr. 66, CH-8134 Adliswil, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer