Open thbar opened 9 months ago
A penser : la recherche devrait-elle renvoyer des articles de doc.transport.data.gouv.fr ?
@AurelienC à terme on pourrait avoir ce type d'intégration effectivement (hors périmètre pour le moment), ça pourrait avoir du sens
DRAFT - document en cours d'évolution. Very WIP
Besoins en cours sur la description de l'existant:
Répartition des informations (Notion vs GitHub)
Je travaille avec @AurelienC là dessus et on répartit les informations à deux endroits, mais sans se marcher sur les pieds:
Brief général
Le moteur de recherche actuel présente plusieurs inconvénients que j'ai proposé de traiter en faisant d'une pierre deux coups :
Ce deuxième point est d'autant plus marqué que l'on ne permet la recherche que sur un nombre tout petit d'items (~500 datasets), mais avec un coût de calcul qui est très important par rapport à cette taille ! Et que par ailleurs, ces items changent très peu!
Approche pas du tout adaptée donc, que de recalculer ces éléments lourds à chaque requête de pagination. Et qui bloque aussi la capacité à apporter des recherches plus riches.
J'ai proposé de travailler dessus et on a validé ce point en objectif trimestriel, voilà donc la démarche que je propose.
L'idée générale est de travailler à dégager:
Cela pourra passer par différents prototypes plus ou moins basiques, pour valider le fonctionnement de façon moins coûteuse qu'une intégration réelle, et pour affiner notre réflexion.
Ainsi:
Il faudra évidemment veiller à ce que les payloads d'indexation soient bien maintenues à jour, et bien indexées elles-mêmes.
Voilà pour le brief :smile: la suite à venir !
État général
Aujourd'hui, seuls les datasets sont indexés et recherchables (c'est à dire que le listing obtenu liste des datasets, et non des ressources).
Même si dans les critères de recherche, sont toutefois impliqués des éléments des ressources du dataset.
On peut se poser durant cette refonte, d'ailleurs, la question d'indexer les ressources elle-mêmes. La solution proposée plus haut permettrait de faire cela assez facilement (en créant des payloads d'indexation au niveau de chaque ressource, puis en travaillant en recherche sur une jointure "payload indexation dataset" <-> "payload indexation ressources"), ce qui est un effet volontaire du design.
Champs pris en compte par la recherche actuellement
(WIP - à vérifier et compléter pour ne rien rater)
dataset.type
Extract:
Où est-ce à l'écran (NOTE: je vais les regrouper sur un screenshot unique à la fin - c'est temporaire pour me faire gagner du temps pendant le relevé des éléments)
dataset.has_realtime
(À mieux détailler TB)
https://transport.data.gouv.fr/datasets?loi-climat-resilience=true
L'utilisateur tape des mots, et différents points sont pris en compte:
creuse confluence
): on tombe sur https://transport.data.gouv.fr/datasets/aom/803Mais aussi (en mode "verrue" collé dans le "lieu"):
resource_metadata.modes
resource_metadata.features
TODO:
Possibilités de tri
Il a été rappelé l'importance de pouvoir trier, et ça peut être assez complexe selon sur quel terrain on va, donc je note aussi l'existant ici:
"Quirks" connus ou tickets historiques en lien
Questions et points relevés avec Aurélien
:warning: aujourd'hui, l'essentiel des méta-informations extraites de la donnée ne le sont que pour GTFS et GTFS-RT.
Préoccupation importante (Aurélien autant que Thibaut) que le travail en cours permette de très bien gérer tous les formats du PAN de façon agnostique.