Dear all, Indeed, the layer search offers something Quickfinder doesn't: searching on all layers without any configuration, and the use of operators. Although I think choosing an operator in a global search is not very required (why doing price < 1000 on all layers, there is a pretty good chance you know what layer you're looking for).
From this, I think Michael's idea is pretty good. Make QuickFinder just a search bar in the application toolbar. Then you can register any search process to it, which would be a processing alg: might be OSM, FTS or Layer search. I would definitely be ok to do so for QuickFinder. But the question is when... It would take me a bit of time to reorganize the plugin, make FTS generation and search as processing algs (never done that before). I won't be able to achieve this before August. So...is this fair to ask someone to wait that long for a dev and then ask to modify its code to fit in? I have no answer, it's a real question. Best wishes, Denis PS: yes, QuickFinder FTS search handles multiple columns as it supports expressions (you can concatenate the columns). On 06/07/2016 03:27 PM, kimaidou wrote: > Hi all, > > I think it is not really profitable to have multiple plugins. In my > opinion, efforts must be made to merge plugins when possible. In this > case, we have > > * Quick Finder : Full Text Search is used here, which allows fuzzy > search, and is very efficient compared to scanning all features for a > match. A drawback, you must fill in the "FTS vectors" for each layer > you want to be able to search within. I think it is not so bad because > the process is fast. I also think there is nothing preventing to add > more than one field in the search ( it is possible with FTS in > PostgreSQL, must also be the case with sqlite) > > * Layer search : Great to have a quick way to search among all the > fields of all loaded layers, with no configuration. Drawback : I think > this can be very slow for big datasets, and it is not "fuzzy", as > regexp are used while iterating on each feature. Another drawback : > for external vector sources like PostgreSQL, all features must been > fetched ! > > IMHO, the way to go could be > > * Add the FTS pregenerator of Quick Finder in Processing, as an alg > available for anyone to use > * Add the FTS search of Quick Finder as a Processing Alg > * Add the "layer search" worker as an Alg in Processing > * Have a combined plugin which let the user choose the search type : > FTS with pregeneration, or direct search with features iteration. This > will then run the corresponding alg > > Cheers, > Michaël > > 2016-06-07 7:16 GMT+02:00 Jeremy Palmer <[email protected] > <mailto:[email protected]>>: > > > > > > I would personally prefer keeping it as a separate plugin, but > what do you > > think? Should it be integrated with another plugin? > > > > It seems like it has value over the other plugins. Another issue > I’ve had is searching all layer fields and pushing the query > filter down the provider (e.g PostGIS or WFS) to increase the > performance and usability. Using the approach of iterating through > all features client side with a large dataset can be a killer in > terms of bandwidth, memory and time. Does your new plugin do that? > If so then it would be really useful :) > > > > This message contains information, which may be in confidence and > may be subject to legal privilege. If you are not the intended > recipient, you must not peruse, use, disseminate, distribute or > copy this message. If you have received this message in error, > please notify us immediately (Phone 0800 665 463 or > [email protected] <mailto:[email protected]>) and destroy the > original message. LINZ accepts no responsibility for changes to > this email, or for any attachments, after its transmission from > LINZ. Thank You. > _______________________________________________ > Qgis-developer mailing list > [email protected] <mailto:[email protected]> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
