You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
OS: Windows
Docker version 20.10.24
Docker Compose version v2.17.2
The text was updated successfully, but these errors were encountered:
sathibault
changed the title
Geonames features not returned when queried with osm source.
Geoname features not returned when queried together with osm source.
Apr 10, 2023
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):
The text was updated successfully, but these errors were encountered: