[Qgis-developer] API changes
wonder.sk at gmail.com
Tue Apr 3 16:25:33 EDT 2007
On 4/3/07, nhugent at hispeed.ch <nhugent at hispeed.ch> wrote:
> Hi Martin,
> >- getNextFeature has parameter featureQueueSize. I think this
> >parameter is quite misleading, unused by the code and most providers
> >don't use it. I would suggest removing it and let's use some
> >predefined value for postgres.
> Postgres seems to be the only provider using it. I don't know how important it is for performance there. The strange thing is that it is set from vectorlayer according to the value of mUpdateTreshold, which was originally introduced for screen refresh and not feature queue size. Removing is ok from my side.
I've found out that it the impact can be quite big - when using a
layer with many features it took about 10 seconds to fetch all data
when fetching one feature at the time. When fetching e.g. 100 at once,
rendering time was 3-4 times lower. I've set feature queue size to
200, this should be okay.
> >- is it necessary to call reset() everytime after select() ? It would
> >be simpler if users could do just select() and then getNextFeature().
> >If provider needs to call reset() first, it could be done in select().
> That's right, it could be done directly in select().
> After these changes, it would be good to have a few days to test before merging.
I'm done with the changes I wanted to do. At last there were more of
them than I've thought but I'm quite happy with them:
- support for writing shapefiles (can be found in legend menu)
- geometry factories - it's possible to create geometry from QgsPoint,
QgsPolyline or QgsPolygon - to be used for saving to shapefile,
inserting to spatial index etc.
- highlighting of identified feature - often I didn't know what's the
feature that I've clicked on (or what is it's exact geometry) so now
it will highlight it with rubberband
If there won't be any big problems we can merge back to trunk during
More information about the Qgis-developer