[Qgis-developer] Table join branch
John C. Tull
jctull at gmail.com
Wed Jul 21 18:29:45 EDT 2010
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
More information about the Qgis-developer
mailing list