Get exact result for ht parameter and not the first one

[danceb]

It is a little bit complicated to zoom to a feature by only passing the search text with the ht parameter, if the search term results in more than one entry. The map will zoom to the first entry of the result list and not to the one with the exact search phrase.

Examples with our system:
https://kartenportal.jena.de/?hp=kartenportal_qwc_adressen_v&ht=Markt%207
Searching for "Markt 7" will result in this list in our case:

• Holzmarkt 7
• Markt 7
• Markt 17
• ...

As "Holzmarkt 7" ist the first entry, the map will zoom to the related feature and not to the one for "Markt 7"

The workaround is, to pass the phrase additional in the hf parameter, like:
https://kartenportal.jena.de/?hp=kartenportal_qwc_adressen_v&hf=[["display"%2C"%3D"%2C"Markt%207%20(Adresse)"]]&ht=Markt%207%20

While this is a little bit bulky, wouldn't it be a better way, to zoom to the element with the exact phrase if there is one?

[danceb]

I came across this issue again. Is there a fast to fix solution for this?

[manisandro]

In theory it should only zoom if there is an exact match, see [1] (ht being equal to st here)

[1] https://github.com/qgis/qwc2/blob/master/utils/SearchProviders.js#L425

Edit: exact match => only one result

[danceb]

I think this is not an issue with the SearchProviders from the qwc2 app as the fulltext search service gives me more than one result:
https://kartenportal.jena.de/api/v2/search/?searchtext=Markt%207&filter=kartenportal_qwc_adressen_v

From this results the first entry is than passed to the SearchProviders for zooming - and at this point this is the "exact match".

[manisandro]

So you mean that with limit=1, the fulltext search provider returns the first item instead of the one with an exact match?

[danceb]

Yes, that's exactly the behavior.

[manisandro]

This is ultimately the behaviour of solr, not the qwc-fulltext-search-service. The fulltext search service sends rows [1] to solr according to the passed limit, and it passes sort=score desc, sort asc by default (although this is configurable via search_result_sort). Try enabling debug logging on the fulltext-search-service container (FLASK_DEBUG=1), and then you can see which request is sent to the solr service. You can try tweaking the solr query to see if you can obtain a better result, and in case it could be evaluated whether the such parameters could be either generated or passed as custom configuration from the fulltext-search-service.

[1] https://solr.apache.org/guide/6_6/common-query-parameters.html#CommonQueryParameters-TherowsParameter

[danceb]

I see the complexity here ... Actually I thought about a solution, where not the first search result, which is get with limit=1 is passed, rather than the one with matching display attribute. So at the moment:

Requesting
https://kartenportal.jena.de/?hp=kartenportal_qwc_adressen_v&ht=Markt%207
leads to
https://kartenportal.jena.de/api/v2/search/?searchtext=Markt%207&filter=kartenportal_qwc_adressen_v&limit=1
I assume the feature_id is extracted and send to
https://kartenportal.jena.de/api/v2/search/geom/kartenportal_qwc_adressen_v/?filter=[["gid","=",140175]]
coordinates/bbox is extracted from the result and used as input for zooming the map to this geometry.

What about something like passing the ht parameter directly first:

Requesting
https://kartenportal.jena.de/?hp=kartenportal_qwc_adressen_v&ht=Markt%207
leads directly to
https://kartenportal.jena.de/api/v2/search/geom/kartenportal_qwc_adressen_v/?filter=[[%22display%22,%22=%22,%22Markt%207%20(Adresse)%22]]
coordinates/bbox is extracted from the result and used as input for zooming the map to this geometry.

And if this result is empty (ht and display not matching), in the second step
https://kartenportal.jena.de/api/v2/search/?searchtext=Markt%207&filter=kartenportal_qwc_adressen_v&limit=1
is requested.

[manisandro]

This won't work because display is in general only a column returned by the facet search query in the solr configuration, but there is no guarantee that it exists under that name in the DB record.

[danceb]

Mh, so there is no good solution for this. Indeed it is possible to zoom to the exact result using both hf and ht, so there is a possibility for doing this. It is just not that handy for editors to maintain the links.

[danceb]

I couldn't leave it behind ... ;-)

If the Solr is set up following the documentation [1] actually there should exist a display field within the DB record! The service uses this field for displaying the search results in the search box field.

So as this field should be part of the db and the entity configuration, it could be used as suggested above. And if the field is missing for some reason, there would be the fall back to use the limit=1 filter by id.

[1] https://qwc-services.github.io/master/topics/Search/#fulltext-search-with-solr-backend

[manisandro]

No, the display field is just retuned by the configured query for solr use. The filter hf ultimately operates via data-service, so it accesses the data directly as stored in the database.