Closed johanricher closed 1 month ago
Suite à ce qu'on s'est dit ce matin avec Aurélie, j'ai repris sa proposition. Pour moi il reste 2 questions à répondre avant de mettre ce ticket (qui a été priorisé par @MathieuFV dans la feuille de route interface) en "prêt à développer".
L'API Adresse avec autocomplétion (autocomplete=1
) est faite pour ce besoin de chercher par texte une adresse ou commune, avec des résultats qui sont ordonnés de façon adaptée à un résultat de recherche avec autocomplétion (les voies et communes avec le meilleur score, notamment qui sont les plus importantes, sont renvoyées en premier, etc.).
Cependant, l'API Adresse distingue commune et adresse (type=municipality
et type=housenumber
) et il n'est pas possible d'avoir les 2 dans une même requête qui renverrait des résultats qui mélangerait les 2, par exemple ordonnés par importance
.
D'un point de vue 1) technique, la faisabilité n'est donc pas évidente et 2) UX, mélanger des communes et des adresses dans la liste des résultats pourrait compliquer inutilement l'utilisation. Si l'implé d'une recherche mélangeant les 2 a un rapport rapport coût / avantage qui n'est pas intéressant, mon avis est que l'implé la plus importante est celle de la recherche par adresse, qui est à la fois la plus précise et la plus triviale à implémenter.
Je vous laisse en discuter et trancher @aureliebaton @mmarchois.
Mon avis c'est que le CTA au-dessus du champ ne fait que répéter de façon superflue le placeholder qui se suffit à lui-même (et est lui-même un CTA) et proposerais donc de supprimer le CTA.
Suite à la discussion d'aujourd'hui :
L'implémentation permettra de recherche une adresse. On écarte la recherche par commune seule.
La maquette a été mise à jour pour ne garder que le placeholder dans le champ de recherche, sans la description qui répétait le CTA juste au-dessus. Utiliser un placeholder, appelé "libellé du champ de saisie" dans le DSFR, est une pratique conforme à l'accessibilité.
Aurélie a fait remarquer le fait que la fonctionnalité de recherche serait limitée aux "voies nommées" (celles qui sont dans la BAN) et ne permettrait pas de recherche d'autres types de voie, en particulier les routes numérotées ou nommées de la BD TOPO (départementales, nationales, etc.). Cette fonctionnalité existe dans l'UI de création d'un arrêté mais nécessite 2 champs (pour filtrer d'abord par commune). Elle serait sans doute utile pour aider à naviguer sur la carte mais il faudra alors explorer le design / UX pour une implémentation ultérieure : https://github.com/MTES-MCT/dialog/issues/891
Je vais mettre à jour la description du ticket pour refléter ces décisions d'implémentation.
J'ai mis à jour la description du ticket pour refléter l'aboutissement de l'exploration, c'est prêt à développer.
Je reviens sur ce ticket suite à #874 où j'ai constaté suite à une review de la qualité des données importées qu'une recherche sur la carte aurait été très utile
J'ai bien compris en lisant la discussion qu'une recherche "d'adresses" uniquement avec l'API Adresse avait été choisie
Mais...
Est-ce que par "adresse" on voulait dire "numéro" ? https://adresse.data.gouv.fr/api-doc/adresse
Car quand on choisit ça et que je saisis un nom de rue, je n'ai aucun résultat
Il faudrait donc choisir le type "rue" non ?
Aurélie a fait remarquer le fait que la fonctionnalité de recherche serait limitée aux "voies nommées" (celles qui sont dans la BAN) et ne permettrait pas de recherche d'autres types de voie, en particulier les routes numérotées ou nommées de la BD TOPO (départementales, nationales, etc.).
Quand on choisit le type "rue" j'ai bien des résultats si je cherche une RD par exemple
Par contre, quand on recherche une commune en pensant que le champ est capable de le supporter, on peut avoir des résultats qui ne correspondent pas du tout. Par ex si je cherche "Wattignies", je tombe sur la "Rue de Wattignes" dans diverses villes (Paris, Lille, Tourcoing...) mais aucun résultat à Wattignies même. Donc la recherche me serait inutile pour un cas d'usage "Où est Wattignies pour y voir rapidement les restrictions en place ?"
Ce qui est confusant
C'est l'API qui est utilisée dans la recherche Géoportail https://www.geoportail.gouv.fr/carte
Elle prend en entrée un texte et renvoie des résultats multi-types triés par ordre d'importance. Au niveau UX tout est présenté dans une section "Lieux ou adresses" .
Donc si je tape Wattignies le premier résultat est bien la ville de Wattignies. Si je tape Rue de Wattignies, j'ai bien lesdites rues dans diverses villes, etc.
Les RD, PR/abs, etc sont aussi supportés
Personnellement, je pense qu'il faudrait réviser le choix fait à date dans ce ticket
Il me semble que l'API Autocomplétion 2.0 de l'IGN + une liste qui mélange tous les résultats pourrait être préférable
En effet
Vu ensemble (Aurélie, Florimond, Mathieu F) aujourd'hui : On teste d'implémenter avec l'API d'autocomplétion de l'IGN.
User story
En tant qu'agent d'une collectivité,
je souhaite positionner la carte sur une adresse en la cherchant par son nom,
afin de voir sur la carte les restrictions dans la zone concernée.
Description
Dans le contexte d'amélioration de la page carte :
659
Le souhait est que les utilisateurs puissent trouver une adresse sur la carte à l'aide d'un champ de recherche plein texte. Il ne s'agit que de fournir un résultat de recherche, puis de géocoder celui-ci, tel que le permet l'API Adresse avec autocomplétion (
autocomplete=1
). Une fois cette recherche effectuée, les utilisateurs utilisent directement la carte pour naviguer et trouver les restrictions recherchées, puis cliquent dessus pour afficher les informations dans un pop up.Design
Le champ de recherche est inséré dans le menu latéral dédié à la recherche ("Visualiser les restrictions") :
Maquette de référence
Critères d'acceptation