Open sathibault opened 1 year ago
Hi @sathibault unfortunately this is contrary to the feature request to have these rows deduplicated.
Most users expect only a single copy of a place in the results, even when they exist in multiple different sources.
I agree it's a little confusing that you've specified two sources and only got one, think of it as an OR not as an AND, the order also doesn't affect deduplication preference.
You can either use the method you mentioned above (explicitly requesting the single source) or edit the code yourself to change this behavior.
We wouldn't consider changing this behavior in the master branch.
I this case the results are not duplicates. The deduplication is removing the correct result.
The search is for Diamantina River which is not returned:
$ curl -s "http://localhost:4000/v1/search?text=diamantina+river&sources=gn,osm" | jq '.features[]|.properties.name' "Diamantina River Road"
However, it is gn:
$ curl -s "http://localhost:4000/v1/search?text=diamantina+river&sources=gn" | jq '.features[]|.properties.name' "Diamantina" "Diamantina Reserve" "Diamantina Dam" "Diamantina River" "Diamantina Island" "Mount Diamantina" "Diamantina Lakes Station" "Diamantina National Park" "Diamantina Lakes Airport" "Diamantina Plains Bore"
Describe the bug When querying via /v1/search API, geoname features are missing from the results when the source=gn,osm that are returned as expected when the source=gn.
Steps to Reproduce Using a Pelias server built using the docker/project/australia setup:
Query explicitly from gn:
curl -s "http://localhost:4000/v1/search?text=diamantina+river&sources=gn"
returns 10 results from gn.Query with both sources:
curl -s "http://localhost:4000/v1/search?text=diamantina+river&sources=gn,osm"
returns 1 result from osm.Expected behavior
The query with both source osm, and gn was expected to return all 11 results (1 from osm, 10 from gn).
Environment (please complete the following information):