On 19.11.2013 09:12, Radim Blazek wrote: > On Mon, Nov 18, 2013 at 8:58 PM, Matthias Kuhn <[email protected]> wrote: >>>> As far as I know, currently the most appropriate thing is to use >>>> layer.dataProvider().addFeatures() and to skip the edit buffer. >>> That is what I am doing, but QgsMemoryProvider::addFeatures() >>> overwrites original feature id. >> It will return a (list of) new feature with the real id: >> >> status, features = l.dataProvider().addFeatures( feats ) >> features[0].id() > I see, that is what I was looking for, thanks. > >>> Another issue with writing directly to provider is, that attribute >>> table is not updated. So how to programmatically change features >>> avoiding edit buffer? >> I think we should rather fix this issue. I would very much like >> QgsVectorLayer to emit a signal, when it commits the features and >> changes their ids. >> >> QgsVectorLayer::featureIdsChanged( QMap< QgsFeatureId, QgsFeatureId ) >> >> So you could connect to this and would not be forced to directly >> interact with the dataprovider. > It would be nice to be able to modify data through vector layer but > - without showing editing mode in legend > - avoiding editing buffer (don't need to fiddle with id changes) > - modify more features in one call, i.e. the same methods as provider > (hopefully to make efficient sending signals to attribute table) > > OTOH, provider should also have a chance to let layer know about > changes, for example dynamic layers or ongoing discussion about > topological editing (multiple layer with the same source).
Agreed, I don't think this is possible yet. This would solve some of the problems you outlined above. Concerning the efficiency of sending signals to the attribute table, I think it would be good, if besides the QgsVectorLayer::featureAdded( QgsFeatureId ) signal another signal QgsVectorLayer::featureAdded( QgsFeature& feature ) would be introduced. This way, it would not be necessary to create a new feature request with a FilterFID for every new feature the table receives. I guess this would already avoid a lot of overhead. And then we could also send batch signals like we do for QgsVectorLayer::selectionChanged so there would be only one signal instead of one per feature. Matthias > > Radim > >> Matthias >> >>> Radim >>> >>>> But I >>>> think that layers should broadcast information about changing feature >>>> ids. This is not a problem unique to the memory provider. >>>> >>>> Matthias >>>> >>>> On Mon 18 Nov 2013 17:25:39 CET, Radim Blazek wrote: >>>>> Is there a trick how to keep track of features added to memory provider? >>>>> >>>>> Say that feature with id is added to a memory provider. Original id is >>>>> overwritten by the memory provider. How to access the feature in the >>>>> provider by original id without additional attribute or hacks like >>>>> counting mNextFeatureId outside the provider. >>>>> >>>>> Radim >>>>> _______________________________________________ >>>>> 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
