[locator] Allow locator filters to support more than one target

[klavspc]

Allow locator filters to support more than one target

Date 2018/06/21

Author Klavs Pihlkjær (@klavspc)

Contact klavspc@gmail.com

maintainer @nyalldawson

Version QGIS 3.4

The original pdf version of this proposal: QgsLocatorFilter-Proposal-Targets.pdf

Summary

This proposal covers extending the locator architecture to allow locator filters to register more than one target. For a specific set of use cases this proposal will enable

• quicker search responses,
• less use use of resources in qgis, and
• a user friendly locator setup ui

In the following sections a fictive geonames locator filter is used as example

A geonames locator filter

The GeoNames geographical database covers all countries and contains over eleven million placenames that are available for download free of charge. Geonames.org maintains Geonames and publishes it both for download and through a search web service

A GeoNames QGIS plug-in could register with the locator and, by using this search service, give the user the ability to search geonames directly in the built-in QGIS locator.

To be as user friendly as possible the plugin may want to represent the nine feature classes as individual targets in the locator:

Today, the plugin can only achieve this by registering nine separate locator filters. This is absolutely doable, but it has two major drawbacks:

1. Multiple http requests causing considerable overhead
   Each filter, representing a feature class, is called resulting in a separate call for each target. That’s a considerable overhead when a search request against geonames allows querying any combination of feature classes in a single request
2. A messy settings page
   

Proposed Solution

• Let QgsLocatorFilter expose a method targets() which will return an array of target definitions consisting of { targetId / displayName / prefix } sets.
• The class QgsLocatorContext is extended with a targetIds array such that when QgsLocatorFilter.fetchResults( QString &string, QgsLocatorContext &context, QgsFeedback feedback ) is called it knows which feature types to retrieve.

Request time

• Filter implementation:
  A geonames locator filter may now determine the necessary featureClass query parameter from context.targetIds(). When results are retrieved and signals are emitted, the filter will decorate results with a target property, which will be used to display results correctly.
• Locator UX:
  The result list in the locator will not be any different under this proposal.

Configuration time

• The QgsLocatorOptionsWidget may now present the targets of the geonames locator filter like this:
  

Affected Files

• QgsLocatorFiltersModel needs to be changed in order to support the hierarchical structure to be presented in the Options|Locator dialog.
• Logic in QgsLocator needs to be updated. Both in regards to what needs to be presented to the locator widget and how targets are determined and filters are called.
• QgsLocatorModel will have to be extended to evaluate filter / target information in addResults (bool addingFilter)
• It must be decided whether to expand QgsLocatorFilter or create a new class MultiTargetQgsLocatorFilter. I favor keeping QgsLocatorFilter as the changes may easily be implemented in the existing class while backwards compatibility is maintained.

Performance Implications

The performance of searches against multiple-target services may be greatly improved

The performance cost of the extra logic in the locator architecture is negligible.

Backwards Compatibility

Backwards Compatibility is easily obtained and should be a requirement such that existing locator filters continue to function. Several options exist. In prioritized order I suggest:

1. A new flag FlagMutipleTargets may be defined,
2. The locator may test whether a filter implements targets or
3. iface is extended with a registerLocatorFilter2()

Votes

(required)

[rduivenvoorde]

@klavspc just for my clarity: why not just search for all feature classes, and filter in your filter implementation. We have something similar in NL here: there is a solr based search service, which you can specify feature types for, but it is just easiest to search for everything and split the result in the filter:

https://github.com/rduivenvoorde/pdok_locatieserver_locator_filter/blob/master/pdoklocatieserverfilter.py#L130

In your screendump your prefixes are rather large: 'stream, lake', while (I think) the purpose of this is to be able to quickly search for something like in our case: 'pdok 2022zj' a zip location in our national PDOK search service.

Another option would be to have one locator for the geonames service, but a small configuration window in which you can choose which featuretypes you want to have returned (as from the geonames api I understand you can ask several at a time)..

Or am I missing your point here?

PS I would claim geon or gnames or gnam quick for this service :-)

[rduivenvoorde]

Ah, duh, not related, but you do not want to see this :-)

So should people register? Or is it the locatorfilter that is registred then as an application?

[klavspc]

@rduivenvoorde: Thank you for your questions.

1. This is about giving the user the ability to search specific targets either by enabling/disabling them in the options or by selecting one in the locator. No matter how many or few targets are selected only one request will be sent to the service. This is the optimization.
2. The user's selection of targets could of course also be done in a settings page specific to the plugin, but that would be against the spirit of how locator options are to be set.
3. By following your suggestion the locator wouldn't be able to sort and present the results by targets as it wouldn't have any knowledge of these.
4. Please take the fictive geonames plugin in my proposal as just an example of a multi-target locator filter

I hope this clarifies my intention with the proposal

[nyalldawson]

I favor keeping QgsLocatorFilter as the changes may easily be implemented in the existing class while backwards compatibility is maintained.

+1

[nyalldawson]

A new flag FlagMutipleTargets may be defined,

+1

[nyalldawson]

@rduivenvoorde

In your screendump your prefixes are rather large: 'stream, lake', while (I think) the purpose of this is to be able to quickly search for something like in our case: 'pdok 2022zj' a zip location in our national PDOK search service.

FYI - @3nids implemented user-overrides of prefixes in 3.2. So I'm generally in favour of more-specific default prefixes for plugin based services, and leave this up to users to customise according to their particular needs and set of installed plugin services.

[nyalldawson]

I've looked over this proposal and I think it's a good approach to solve this problem. So I'm a +1 overall here.

One small thing I'd like to see when implemented relates to the screenshot of the config panel with multiple targets - instead of the "- Country ...." approach for showing the targets, we should put these items as proper children under the parent filter.

[3nids]

I have been facing similar issues when implementing a locator for the Swiss Geoportal. I ended up doing 3 filters but not for the exact same reasons. My main issue was that I am having different requests for each sub-search (i.e. 3 different URLs I cannot combine) although they do belong to the same locator.

I am not sure how this is compatible with this proposition, but I'd like to be able to have a fetchResults per sub-filter. I'd have to think a bit more about it.

Also, in one of my 3 filters, I would also have sub-categories similarly to your problem. For this part, I only have a table in the options where I can select sub-categories. Having something more accessible would be awesome. Maybe an auto-completion for the sub-categories?

[lennoo]

I wanna one entry to locate multi layers features