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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
