Hi John Yes, an export adds all the joined fields to the new layer. So this provides a good workaround if the join performance is too slow.
Regards, Marco Am Donnerstag, 22. Juli 2010, um 00.29:45 schrieb 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 [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
