Price/proof addition : location field : restrict OSM types #5568
Comments
|
@raphodn I've just run some default search - https://photon.komoot.io/api?q=berlin&bbox=9.5,51.5,11.5,53.5 {
"geometry": {
"coordinates": [
9.7517684,
52.3738781
],
"type": "Point"
},
"type": "Feature",
"properties": {
"osm_id": 185830087,
"extent": [
9.7517684,
52.3738781,
9.7517784,
52.3734873
],
"country": "Allemagne",
"city": "Hanovre",
"countrycode": "DE",
"postcode": "30159",
"locality": "Bult",
"county": "Région de Hanovre",
"type": "street",
"osm_type": "W",
"osm_key": "highway",
"district": "Ville-Sud-Bult",
"osm_value": "secondary",
"name": "Berliner Allee",
"state": "Basse-Saxe"
}
},Btw wouldn't an inclusion list or a search filter be more relevant, like https://photon.komoot.io/api?q=berlin&bbox=9.5,51.5,11.5,53.5&osm_tag=shop? |
|
The exclusion list looks at :
And what is stored (and displayed) afterwards per location :
Bonus : the current top 30 location types in OP
there are prices everywhere, not only supermarkets, but also pharmacies, restaurants, bakeries, bookstores... is it possible to have dozens in the inclusion list url ? |
|
|
@raphodn According to your stats, I guess we would be ok in a first approach filtering on |
|
the stats are just for info, there are 900+ locations so only a subset show up in the top 30 types, at no moment did I say we should restrict... but they DO show that places like house or city have been used as locations. Recently I've been adding prices in restaurants, greengrocers, diy shops, bars, pharmacies... so i'm in favor of as much choices as we can give the user. So probably sticking with a blacklist rather than a (long aka "dozens" as stated above) whitelist |
You meant a blacklist that doesn't restrict? Besides
|
|
oook my bad, i re-read the whole thread, I understand now what you mean, by filtering on the the full list of location types : https://gist.github.com/raphodn/7c53c4a3403f0f86e89f09e9e7a7ddaf |
|
@raphodn Of course for better stat analysis we should see how many prices are used with "right" or "wrong" locations, but from what I could see in your list whitelisting to shopamenityno shop and no amenity |
|
ok following this discussion I opened a PR in the web frontend. I had a look at the Do you think we should add |
|
The question is: how to deal with crap OSM data, before we put it in Prices and after. As a user, I find it very painful to find "carrefour" shops in Paris because both "carrefour" and "Paris" have different meanings:
Therefore I would really appreciate being able to enter just "carrefour paris" without ambiguity when talking about shops. That said, "your" LIDL cannot be found as a In parallel, we may enhance the whitelist. |
|
After a few hours thought (and some previous discussions on the subject), I would go with :
|
|
I may have an even better solution:
2 API calls being transparent for the user that sees a single sorted list. |
|
So you would combine the 2 results ? it might "bloat" the results. but the idea of opening up the search is good, it could be a user action;
|
|
@raphodn This is what I have in mind:
With this we provide the user with a better UX (e.g. "carrefour paris" really delivers shops), while letting the OSM data being slightly crappy. What do you think of that?
|
Some users are adding prices and linking them to non-desired locations like cities, countries, roads...
In the Open Prices web frontend we remove some OSM POI results using a blacklist, to avoid having proofs/prices linked to a non-shop location.
The list can be seen here : https://github.com/openfoodfacts/open-prices-frontend/blob/master/src/constants.js >
NOMINATIM_RESULT_TYPE_EXCLUDE_LISTLinked frontend issue : openfoodfacts/open-prices-frontend#37
If needed, we could move this blacklist to the backend, and have it available via an API endpoint ?
The text was updated successfully, but these errors were encountered: