Filtrer les restrictions par leur localisation

Description

Dans le cadre de #202

2 options envisagées et à investiguer

Filtre par géométrie : renvoyer les restrictions dont la géométrie est comprise dans celle du lieu recherché (commune par exemple)
Filtre par métadonnées (champs localisations, distincts pour "voie" et "route départementale") : renvoyer les restrictions présentes sur la localisation recherchée

Exploration

En cours.

Option 1 - Filtrage par géométrie

Principe :

Quand on saisit du texte dans le champ "Recherche par lieu", une liste de suggestions apparaît
- La liste contient différents types de lieux : communes, voies nommées, routes numérotées (RD, etc)
Quand on sélectionne une option dans la liste, sa géométrie est utilisée pour filtrer les restrictions : on ne garde que les restrictions dont la géométrie recouvre partiellement la géométrie de recherche

Avantages / Bénéfices

Le calcul est simple : en gros c'est une clause WHERE ST_Intersects(:geometry, loc.geometry)
Cette approche couvre tous les types de localisations, présents ou futurs, car elle se base uniquement sur la géométrie (c'est le seul champ commun à tous les types de localisations)

Inconvénients / Risques / Questions ouvertes

Il faut pouvoir générer les options et leur associer une géométrie, or :
- L'API Adresse ou l'API Géocodage IGN ne renvoient que des géométries de type point (coordonnées x/y), ce qui ne permet pas de faire un calcul d'intersection
- La BDTOPO thème Transport ne contient pas de table qui liste les communes
- => Quel service ou base de données permettrait d'obtenir une liste "d'entités" et leur géométrie "réelle" (aire géographique, linéaire, point) ?

Option 2 - Filtrage par métadonnées de localisation

Principe :

Quand on saisit du texte dans le champ "Recherche par lieu", aucune liste de suggestion n'apparaît (comportement de recherche, mais pas d'autocomplete)
On ne garde que certaines restrictions, selon la méthode suivante :
- On recherche dans les localisations de type "voie nommée" celles où la commune ou le nom de voie "correspondent" au terme de recherche (algorithme "fuzzy search" pouvant se baser sur le full-text search (FTS) de Postgres)
- On fait de même dans les localisations de type "route départementale" en recherchant par numéro de route et gestionnaire
- Un "poids" est associé aux différentes colonnes (par ex si la commune match, on peut préfèrer la faire remonter plus haut dans les résultats que la voie, exemple de "Commune = Rouen" vs "Voie nommée = Rue de Rouen"), avec le système de weight du FTS Postgres
- Les restrictions retenues sont celles qui concernent une localisation présente dans l'une de ces listes de résultats
- Pour la liste, la question de l'ordre d'affichage se pose. En général on trie par "pertinence". Le FTS de Postgres fournit un score de pertinence pour une recherche donnée, mais il faut voir s'il peut être "normalisé" pour combiner des résultats issus de 2 requêtes différentes.

Avantages / Bénéfices

Permet de rechercher à partir du texte saisi par les utilisateurs dans les différents champs

Inconvénients / Risques

Complexité d'implémentation liée à la distinction des cas selon le type de localisation
Dans cette approche, l'UX "champ de recherche unique" complique la chose, si on compare à une UX où on aurait 1 champ par colonne (1 champ "Commune", 1 champ "Nom de la voie", 1 champ "Numéro de route"), puisque dans ce cas-là on pourrait largement réutiliser les autocompletes du formulaire
Ne permet pas de faire remonter les données type "RawGeoJSON", donc ça exclut les données JOP, les données Litteralis et à l'avenir d'autres données obtenues sans géocodage DiaLog
Dédoublement partiel de la logique de recherche présente dans les formulaires
Comment indiquer pourquoi tel élément a été retenu ? (Sur la liste de l'annuaire des entreprises, il y a des termes surlignés en jaune, ce que le FTS de Postgres peut nous fournir ; mais sur une vue carte, comment le matérialiser ?)

Là on aborde des questions sur la faisabilité technique, ce qui est indispensable pour décider ce qu'il est préférable d'implémenter, mais si on prend un peu de recul se pose aussi la question de comment va être interprêté et utilisé un tel champ de recherche.

Est-ce que si je tape "paris" dans la recherche je m'attends à ce que

La carte se positionne sur Paris mais sans que ce positionnement ait un effet sur le filtrage des données sur Paris (le comportement actuel sur la page carte, celui d'Airbnb, etc.)
La carte se positionne sur Paris et n'affiche que les restrictions dont la géométrie recouvre au moins partiellement la géométrie du lieu recherché (proposition discutée ici avec l'option 1 de filtrage par géométrie)

Dans ce scénario de filtrage par géométrie, quel est le comportement si je fais une recherche sur une rue ou une adresse ?

On a une ambiguité d'UX entre le filtrage des restrictions par leur localisation et sur le positionnement de la carte (qui doit ou pas changer le filtrage).

Il me semble nécessaire de bien distinguer ces aspects d'UX (positionnement de la carte et filtrage par localisation).

C'est pour ça que Je propose de privilégier l'option 2 et de faire une fonctionnalité de filtrage des restrictions par "zone géographique" (c'est à dire un ou plusieurs filtres parmi d'autres comme le filtre par type, par organisation, etc.) et de laisser les utilisateurs positionner la carte par un zoom sur la carte (comme sur l'Annuaire des entreprises) ou éventuellement par un champ "Chercher un lieu", avec la même implé que le champ de recherche actuel, mais bien distinct des fonctionnalités de filtrage des restrictions, sur la carte, afin de bien enlever toute ambiguité UX.

Mes réponses sur l'option 1 de filtrage par géométrie :

Quel service ou base de données permettrait d'obtenir une liste "d'entités" et leur géométrie "réelle" (aire géographique, linéaire, point) ?

Ca existe mais c'est pas forcément exhaustif donc du point de vue utilisateur ça risque de poser des problèmes.

L'API Géo (découpage administratif) renvoie des contours en GeoJSON pour certaines entités (communes et EPCI je crois)

L'équipe data.gouv.fr publie des GeoJSON sur les contours administratif mais, pareil, pas forcément exhaustif

Sur l'option 2 :

Dans cette approche, l'UX "champ de recherche unique" complique la chose, si on compare à une UX où on aurait 1 champ par colonne (1 champ "Commune", 1 champ "Nom de la voie", 1 champ "Numéro de route"), puisque dans ce cas-là on pourrait largement réutiliser les autocompletes du formulaire

Je proposerais d'avoir un seul champ "Filtrer les restrictions par leur localisation" dont le comportement serait par exemple :

Si je cherche une commune, ça filtre sur toutes les restrictions avec une localisation associée à cette commune (donc seulement les restrictions sur une "voie")
Si je cherche une rue, ça filtre sur toutes les restrictions avec une localisation associée à cette rue (donc seulement des restrictions sur une "voie")
Si je cherche une RD, ça filtre sur toutes les restrictions avec une localisation associée à cette RD (donc seulement des restrictions sur une "RD")
Si je cherche un département, ça filtre sur toutes les restrictions avec une localisation associée à ce département (donc seulement des restrictions sur une "RD")
Je ne peux pas chercher autre chose à priori pour l'instant (tant qu'on a que des "voies", des "RD" et les localisations associées)

Ne permet pas de faire remonter les données type "RawGeoJSON", donc ça exclut les données JOP, les données Litteralis et à l'avenir d'autres données obtenues sans géocodage DiaLog

Pour moi ces cas d'usage dont tu parles ne sont pas directement liés à la dimension géographique des données DiaLog et pourraient bien mieux être adressés par un champ de recherche plein texte (tel que je le propose sur #202), un filtre par organisation, et éventuellement d'autres filtres (pourquoi pas par "source", si on ajoutait une métadonnée sur le logiciels d'où proviennent les données qu'on intègre)

Dédoublement partiel de la logique de recherche présente dans les formulaires

Pas compris

Comment indiquer pourquoi tel élément a été retenu ? (Sur la liste de l'annuaire des entreprises, il y a des termes surlignés en jaune, ce que le FTS de Postgres peut nous fournir ; mais sur une vue carte, comment le matérialiser ?)

Ca ne me semble pas poser problème sur la vue carte de l'annuaire des entreprises.

Je réponds en vrac à différents points

On a une ambiguité d'UX entre le filtrage des restrictions par leur localisation et sur le positionnement de la carte (qui doit ou pas changer le filtrage).

Oui

Pour le centrage de la carte, d'un point de vue utilisateur ça me semblerait logique que n'importe quel champ "lieu" ait une action de centrage

Mais si on veut juste centrer, ça se ferait plutôt par un petit champ sur la carte, en mode widget ?

L'équipe data.gouv.fr publie des GeoJSON sur les contours administratif mais, pareil, pas forcément exhaustif

Ces fichiers ont quand même l'air exhaustifs, il y a 35 074 features qui couvrent les 98 codes départements, sachant que (source wikipédia) il y a 35 028 communes au total (hexagone et outre-mer)

Avec un tel fichier, on pourrait implémenter un filtrage géométrique en recherchant une commune. Ce que je trouverais déjà très intéressant et peu sujet à ambigüité !

Et se restreindre aux communes résoudrait la question "Dans ce scénario de filtrage par géométrie, quel est le comportement si je fais une recherche sur une rue ou une adresse ?"

(Est-ce qu'une recherche par rue était d'ailleurs si intéressant comme cas d'usage ? Sachant que dans la rue il faut inclure la ville sinon on va afficher les restrictions de toutes les "rue de la république" de France)

Si je cherche un département, ça filtre sur toutes les restrictions avec une localisation associée à ce département (donc seulement des restrictions sur une "RD")

Petite attention, pour les routes numérotées, le champ qu'on a c'est le "gestionnaire" (ce qui inclut les départements mais pas que)

si on ajoutait une métadonnée sur le logiciels d'où proviennent les données qu'on intègre

Pour info, on a déjà un tel champ source, qui vaut dialog, eudonet_paris, bacidf, jop ou litteralis aujourd'hui.

En lisant vos commentaires à tous les deux (merci pour tous ces détails, même si beaucoup m'échappe), j'ai du mal à trancher pour l'une ou l'autre option. Ce qui me semble important c'est de répondre au cas d'usage : "Quelles sont les restrictions près de chez moi ou sur ma commune ?". Il est important que le champ de recherche puisse aider à la localisation (avec l'autocomplétion pour éviter aussi les erreurs de saisie) sur la vue carte et la vue liste. OK ça vous aide pas tellement ;)

Autre question : Est-ce que l'une ou l'autre option est plus "coûteuse" que l'autre en terme de performance, écoconception, etc ?

Je sais pas si ça peut aider mais j'ai fait une petite liste de cas d'usage et utilisation potentielle de la carte et listing. Ce n'est pas exhaustif, mais moi ça m'aide ;)

-- En tant qu’agent public, je veux voir les restrictions de circulation sur mon territoire.

Sur la vue carte, je rentre le nom de ma ville dans le champ de recherche (ex : Rouen).
Je vois de nombreuses restrictions s’afficher sur la carte.
Je passe à la vue liste pour avoir une vue d’ensemble des restrictions (les résultats sont définis en fonction de ce qui est entré dans le champ de recherche indépendamment du zoom)
Je peux affiner ma recherche sur une rue spécifique ou faire un CTRL F dans la page ;)
Par défaut l’ordre des restrictions est défini par la date (période d’application) et par ordre alphabétique des rues ? Un filtre de type “sort by” pourrait être dispo en haut de la liste ?

En tant qu’agent de mairie, je veux voir les restrictions sur ma commune afin de communiquer avec les habitants (exemple partage du lien DiaLog ou intégration de la carte sur le site de la mairie). (Voir ci-dessus)

En tant qu’entreprise de travaux, je veux voir si les travaux sur lesquels je vais travailler sont bien indiqués sur la carte et aux bonnes dates.

Sur la vue carte, je rentre le nom de la rue et la ville dans le champ de recherche (ex : Boulevard des Belges, 76000 Rouen).
La carte zoom sur la zone, je vois les restrictions sur le boulevard et les autres travaux potentiels dans la zone.

En tant qu’entreprise de transports publics, je veux voir les travaux prévus sur mon territoire afin d’anticiper les déviations.

Sur la vue carte, je rentre le nom de la ville.
Je passe à la vue liste pour avoir la vue globale des rues/voies impactées et si elles sont sur les trajets des bus
J’identifie les rues qui me concernent et je les copie/colle pour les transmettre, les rentrer dans mon système de gestion, etc.

En tant qu’agent public, je veux vérifier que les restrictions publiées sont bien affichées sur la carte dans mon territoire.

Sur la vue carte, je rentre le nom de la rue et la ville dans le champ de recherche (ex : Boulevard des Belges, 76000 Rouen).
La carte zoom sur la zone, je vois les restrictions et je clique pour voir les détails.

En tant qu’usager de la route, je veux voir les perturbations près de chez moi pour anticiper mes trajets.

Sur la vue carte, je rentre le nom de la rue et la ville dans le champ de recherche (ex : rue Arthur Duval, 76000 Rouen).
Je vois les perturbations autour de chez moi.

En tant qu’agent de mairie, je veux voir les restrictions sur ma commune afin de communiquer avec les habitants (exemple partage du lien DiaLog ou intégration de la carte sur le site de la mairie). (Voir ci-dessus)

Est-ce que ce cas serait mieux / plus efficacement / plus robustement traité par la reprise du filtre "organisation" sur la vue carte ?

En tant qu’entreprise de travaux, je veux voir si les travaux sur lesquels je vais travailler sont bien indiqués sur la carte et aux bonnes dates.

Dans ce cas on a donc bien seulement un zoom sur la carte ? Je suis d'accord que c'est bien de ne pas filtrer car ça permet de voir ce qu'il se passe dans les environs

Au final dans ta description on dirait que

Le filtrage serait surtout quand on cherche une commune ; quand on cherche une rue on va plutôt vouloir zoomer en gardant l'aperçu des alentours
Le filtrage est bien + important côté liste que côté carte ?

En tant qu’agent de mairie, je veux voir les restrictions sur ma commune afin de communiquer avec les habitants (exemple partage du lien DiaLog ou intégration de la carte sur le site de la mairie). > (Voir ci-dessus)

Est-ce que ce cas serait mieux / plus efficacement / plus robustement traité par la reprise du filtre "organisation" sur la vue carte ?

AB : Effectivement, le filtre Organisation fait partie des filtres que nous avions envisagés mais pour l'instant que nous n'avions pas priorisé (la recherche étant prioritaire).

En tant qu’entreprise de travaux, je veux voir si les travaux sur lesquels je vais travailler sont bien indiqués sur la carte et aux bonnes dates.

Dans ce cas on a donc bien seulement un zoom sur la carte ? Je suis d'accord que c'est bien de ne pas filtrer car ça permet de voir ce qu'il se passe dans les environs

AB : Oui c'est exact.

Au final dans ta description on dirait que

1. Le filtrage serait surtout quand on cherche une commune ; quand on cherche une rue on va plutôt vouloir zoomer en gardant l'aperçu des alentours

2. Le filtrage est bien + important côté liste que côté carte ?

AB: Quand tu parles de "filtrage" tu parles pas des filtres sur le côté ? Tu peux préciser ce que tu entends par filtrage dans ce cas ?

@aureliebaton

AB: Quand tu parles de "filtrage" tu parles pas des filtres sur le côté ? Tu peux préciser ce que tu entends par filtrage dans ce cas ?

Je veux parler du fait de cacher les restrictions qui ne correspondent pas à la recherche par localisation

Sur la carte il n'est peut-être pas si important de cacher les points / linéaires de restrictions qui ne sont pas là où on a recherché, on peut se contenter de zoomer

Mais sur la liste, forcément on ne va afficher que ce qui nous intéresse

@aureliebaton

AB: Quand tu parles de "filtrage" tu parles pas des filtres sur le côté ? Tu peux préciser ce que tu entends par filtrage dans ce cas ?

Je veux parler du fait de cacher les restrictions qui ne correspondent pas à la recherche par localisation

Sur la carte il n'est peut-être pas si important de cacher les points / linéaires de restrictions qui ne sont pas là où on a recherché, on peut se contenter de zoomer

Oui tout à fait, c'est mieux de voir de qu'il y a autour. Les cacher serait perturbant, surtout qu'on va ensuite bouger sur la carte et on s'attend à voir toutes les restrictions là on on bouge (c'est pas très clair ce que je dis mais je me comprends ;)

Mais sur la liste, forcément on ne va afficher que ce qui nous intéresse

MTES-MCT / dialog