Recherche de ressources par zone géographique

[thbar]

Je mets à plat une idée qui s'appuie sur 1. les expérimentations faites précédemment et 2. l'envie terrain (réutilisateur) d'identifier les ressources "dans la vraie vie" autour d'un endroit (enquêtes diverses etc), en proposant un schéma relativement simple pour aller vers ce type de fonctionnalité assez facilement.

Si pour chaque format, on met en place un extracteur relativement générique dont le but n'est pas de faire une extraction complète, mais simplement de recracher la donnée de type latitude/longitude (avec peut-être une petite chaîne pour préciser le type de point), soit par exemple:

• GTFS: prendre les arrêts
• GTFS-RT: prendre les vehicle positions (lorsqu'elles sont disponibles), et dans le futur prendre les arrêts du GTFS associé
• Netex: prendre les arrêts
• GBFS: prendre les stations et/ou les véhicules en flottant
• SIRI (quand disponible sur le PAN): prendre les positions arrêts et/ou véhicules
• schéma comptage mobilité: prendre les sites
• autres schémas: voir comment extraire des points

Alors on pourrait avoir une structure de données bien plus légère comparativement à la totalité de la donnée, qu'on pourrait facilement remonter en base, de façon homogène, sous la forme:

• latitude
• longitude
• type

Dans un second temps on pourra aller vers des modèles plus complexe qu'un simple point.

À partir de là, il est trivial d'implémenter un moteur de recherche autour d'une adresse donnée (dans un rayon de N km) ou dans une bounding box, qui permette de lister les ressources du PAN qui correspondent.

J'insiste sur le traitement transverse multi-formats dès le début, car c'est ça qui va faire qu'on aura un traitement "agnostique" et permettra de trouver le dénominateur commun.

[thbar]

Précisions:

• ça pourrait commencer sa vie comme un moteur de recherche "à part" pour faciliter le travail
• pas besoin de s'appuyer forcément sur RessourceHistory (on pourrait avoir des snapshots temporaires pour le temps réel etc)
• l'important est le lien avec le "ressource id" de notre propre base, et le fait de rafraichir ça facilement

[nlehuby]

Je confirme que ça serait cool d'avoir une API qui permette de remonter les jeux de données pour une zone Idéalement, elle prendrait comme paramètres

• des coordonnées et un rayon / une bbox
• des filtres pour affiner le type de jeu de données souhaité (transport en commun, covoiturage, parking, etc)

Et elle retournerait les datasets sur le même modèle que les API existantes, en se basant sur les points extraits décrits plus haut.

[thbar]

Merci @nlehuby pour ton commentaire que j'avais raté !

Pour la partie GTFS, avec les travaux réalisés dans la codebase (et en dernier lieu #3157), on commence à être en mesure de faire ce type de recherche.

[thbar]

Hello @nlehuby! Tu as un premier embryon de ça qui est une API expérimentale qui permet de lister tous les arrêts GTFS présent dans une bounding box (https://transport.data.gouv.fr/swaggerui#/gtfs/API.GTFSStopsController.index).

Ce n'est pas terminé ni complet, mais c'est un premier jet !

Cela réutilise les données GTFS déjà remontées en base chez nous ici https://transport.data.gouv.fr/explore/gtfs-stops et que tu peux retrouver (mais c'est juste une copie à un instant t) ici https://transport.data.gouv.fr/datasets/arrets-de-transport-en-france.

Voilà n'hésite pas si tu as des retours !

[nlehuby]

Hello @thbar, merci de me tenir au courant, en effet, ça semble prometteur !

je comprends pas trop à quoi fait référence le dataset_id (properties.d_id) retourné avec chaque arrêt. Si je le passe à https://transport.data.gouv.fr/swaggerui#/datasets/API.DatasetController.datasets_by_id, ça ne me retrouve aucun dataset :thinking:

[thbar]

Hello @nlehuby! Merci pour tes tests préliminaires :smile:

C'est normal que tu sois perdue, le nom n'est pas clair pour des questions d'optimisations, et ce n'est pas le dataset id mais un "data import id", qui est un suivi d'import d'une version donnée d'un GTFS (https://github.com/etalab/transport-site/blob/master/apps/transport/lib/transport/gtfs_data.ex#L47).

@vdegove est en train de travailler à cette amélioration ici https://github.com/etalab/transport-site/pull/3541 si tu veux suivre !

(nos excuses pour la confusion qui est bien normale - l'API est extraite de la carte, mais la peinture n'est pas encore super sèche sur son usage pour toi).

Merci pour les retours !

[nlehuby]

ok, super !

je trouve ça dommage également de ne pas avoir le mode de transport de l'arrêt, car un arrêt de métro et un arrêt de bus recouvrent quand même des objets assez différents. Mais si c'est basé sur le fichier stops.txt du GTFS, je comprends bien ...

[thbar]

On pourra améliorer ces points pas de souci ! Il faut voir tout ça comme de "premiers jets" (avec beaucoup de boulot derrière pour y arriver certes :smile:), mais nous sommes preneurs des retours justement, et on intègrera ça à notre réflexion dans la roadmap !

[vdegove]

@nlehuby j’ai corrigé l’API, on a à présent un dataset_id. Et tu peux également télécharger ces données ici https://transport.data.gouv.fr/datasets/arrets-de-transport-en-france

[nlehuby]

c'est super ! le mode de transport serait vraiment un plus mais ça me permet déjà d'avancer sur le cas d'usage que j'avais en tête. Merci pour votre beau boulot :+1:

[vdegove]

Je me désassigne, je laisse ouverte l’issue vu que le travail sur la bounding box GTFS ne couvre pas à 100 % le besoin.

[thbar]

Je reprends le flambeau!