Nouvelle amélioration de la recherche d'une catégorie à partir des tags
publié le , mis à jour⚙️ Ceci est une proposition de changement de code.
Rendez-vous sur sa page Coderberg pour l'osculter.
fixes #1088 fixes #1056 contribue à résoudre #1070 discuté ici sur le forum osm fr et aussi sur matrix
Finalement j'opte pour vérifier précisément si les tags du lieu correspondent à une des requêtes overpass de moreCategories.yaml.
Ecrire le parseur n'était pas si compliqué 1) car on ne parse que le filtre sur les tags, pas toute une requête overpass, donc structure plus simple et surtout 2) je me suis bien fait aider du chat mistral qui m'a bluffé.
La suite (comparer le filtre parsé au tags du lieu) est WIP
etienneJr
J'ai progressé :
- j'ai ajouté une fonction pour comparer si un filtre overpass (du genre
[key!~value]) match les tags d'un élément OSM - j'utilise cette fonction pour vérifier si un filtre overpass complet de category (du genre
[amenity=parking][access!~"private|no"]) match les tags de l'élement OSM affiché sur la fiche lieu - je calcule le score de la catégorie seulement si le match est parfait et complet (si l'élément OSM est VRAIMENT membre de cette catégorie)
Donc :
- ça corrige le bug de quand la fiche lieu indiquait une catégorie qui n'avait rien un voir (un amphithéatre quand on consultait une caféteria), et c'est déjà une grosse amélioration !
- en revanche, il y a toujours des cas où plusieurs catégories matchent avec le même score (il faut filtrer la console par
findCategorypour les voir) et je n'ai pas encore enlevé le choix aléatoire, donc c'est encore WIP- exemple typique : quand un key=value apparait de façon semblable dans plusieurs catégories proches. Typiquement les bars/cafés/pub etc => faudrait il supprimer les catégories trop générales ?
- faut que j'investigue les autres cas pour voir comment les gérer
Le fait que certaines catégories soient définies avec 2 query possible, une avec 1 filtre et l'autre avec 2 filtres, semble poser problème. Car par exemple amenity=restaurant se retrouve avec le même score que diet:vegan=yes. Peut-être donner plus de poids si la query contient
:, car ça montre que le tag est plus précis ? Pour que la catégorie plus précise ait toujours un meilleur score que la catégorie générale ?- j'ai ajouté une fonction pour comparer si un filtre overpass (du genre
laem
Excellent ! Je te laisse maitre du sujet, n'hésite pas si tu penses une revue nécessaire de mon côté. Les LLM peuvent en effet être très bonnes pour de l'algorithmie ! Une partie du code de recherche de catégorie avait déjà été écrit par une LLM en partie.
OK, j'ai enfin réussi ce que je voulais faire : afficher (juste au dessus du nom du lieu) notre nom de catégorie avec son icône en remplacement des traductions OSM des soloTags. Je crois que c'était déjà le cas avant mais que c'était cassé depuis longtemps (depuis que j'avais ajouté bcp de catégories)
J'ai encore un peu de mise en forme à faire, et après je pense que ça sera bon (mais j'avoue que je m'y perds un peu dans l'architecture des composants Icons > Icon > MapIcon )
Il faudra aussi que l'icône s'affiche dans les bookmarks, mais ça sera ptêt dans une PR suivante.
Tiens, et si on affichait les 3 gros boutons de la même couleur que la catégorie ? ça ferait une UI pas stable ? ptet un peu trop extrême comme idée...
Autre question : est-ce que, quand la catégorie est trouvée et affichée, je dois afficher les soloTags avec les keyValueTags ? (on risque de rater une info sans ces soloTags ou non ? je ne me rends pas bien compte)
c'est bon pour l'affichage des icones de catégories dans les favoris. Mais mazette je ne suis vraiment pas doué en mise en page ! 😅
d'ailleurs, dans la capture ci-dessus, on voit que l'affichage de l'adresse (3 rue du puits mauger) marche dans QuickBookmarks mais pas dans BookMarks. Je n'ai pas investigué.
@laem j'enlève WIP parce que c'est fonctionnel donc fusionnable. Mais tu as le droit de me dire que ça n'est pas propre (dans le code ou dans l'UI) et qu'il faut que j'améliore tel ou tel truc.
j'oubliais : finalement pour être sûr qu'un lieu s'affiche toujours avec la même catégorie, j'ai enlevé le choix aléatoire qui restait quand on se retrouvait avec 2 catégories qui avaient le même score (genre
bar, café, pubetbar). L'algo prend le premier, donc a priori le plus général, par exemple celui dans les baseCategories plutôt que dans les moreCategories.Il faudra me remonter si des lieux ne sont pas liés à une catégorie (j'ai identifié les magasins d'électroménager Boulanger), ou si l'icone de catégorie ne correspond pas à l'icone de la carte (c'est perturbant aussi !)
Trop cool ! Sur le code, je te fais confiance. J'ai trop peu de temps en ce moment pour regarder et je préfère être pragmatique : ça résout un problème important :)
Tiens, et si on affichait les 3 gros boutons de la même couleur que la catégorie ? ça ferait une UI pas stable ? ptet un peu trop extrême comme idée...
Je préfère pour l'instant garder une couleur simple à comprendre : tous les boutons sont de ce bleu, ou presque. Mais on pourra y réfléchir dans le futur.
@laem wrote in https://codeberg.org/cartes/web/pulls/1092#issuecomment-6890935:
Trop cool ! Sur le code, je te fais confiance. J'ai trop peu de temps en ce moment pour regarder et je préfère être pragmatique : ça résout un problème important :)
OK merci, je merge
@laem je me suis demandé pourquoi tu avais prévu 2 vues différentes :
Mes favorisavec le design en bulles, etGérer mes favorisavec le design en liste. Perso je trouve que la vue en liste est largement suffisante, je serais d'avis de garder uniquement celle là. (mais c'est ptet parce que la vue en bulles est un peu ratée)LySioS
@etienneJr wrote in https://codeberg.org/cartes/web/pulls/1092#issuecomment-6863059:
Tiens, et si on affichait les 3 gros boutons de la même couleur que la catégorie ? ça ferait une UI pas stable ? ptet un peu trop extrême comme idée...
Non, oui, oui 😄