API de recherche de stops GTFS par bounding box

[vdegove]

Cette PR reprend le code déjà fait pour la carte des stops GTFS et le transforme en API :

• Bougé dans un contrôleur dédié
• Tests
• On peut l’utiliser avec juste les coordonnées de la bounding box, là où avant on devait aussi fournir des paramètres propres à la carte javascript (niveau de zoom.) Si trop de points sont contenus dans la bounding box, on renvoie un message d’erreur.

Notes @thbar

• La requête typique est: localhost:5000/api/gtfs-stops?south=48.82&east=2.486&west=2.070&north=48.9677
• Le retour est du JSON ou une erreur
• J'ai documenté l'erreur
• J'ai amélioré la présentation (voir plus bas)
• Pas de régression perf constatée

[thbar]

Je trouverais utile d'avoir une description (désolé si je l'ai ratée) plus explicite dans la doc contrôleur et/ou dans la PR des "deux modes" et de leur fonctionnement, car à la lecture c'est pas évident à comprendre (sachant que le code de la feature est déjà un peu "spécifique").

Je comprends que tant que la personne utilise la feature comme elle est documenté en opération OpenAPI, on restera sur du non clusteré, par exemple, et que si elle se mettait à passer autre chose, on lui retournerait du clusteré.

Cette dualité gagnerait à être décrite explicitement pour qu'on (nous ou de futurs mainteneurs) ne s'y perde pas.

Je ferai un peu de test en local aussi niveau perf pour voir si je ne vois aucun souci, pour l'instant j'ai juste pris le temps de lire le code.

Pas évident à relire sur ce type de PR (sans critique aucune) dans le sens où le code bouge en bloc et est modifié pour les besoins du changement, je ferai une petite comparaison sur deux répertoires pour ne rien rater.

[vdegove]

Je trouverais utile d'avoir une description (désolé si je l'ai ratée) plus explicite dans la doc contrôleur et/ou dans la PR des "deux modes" et de leur fonctionnement, car à la lecture c'est pas évident à comprendre (sachant que le code de la feature est déjà un peu "spécifique").

Je comprends que tant que la personne utilise la feature comme elle est documenté en opération OpenAPI, on restera sur du non clusteré, par exemple, et que si elle se mettait à passer autre chose, on lui retournerait du clusteré.

Cette dualité gagnerait à être décrite explicitement pour qu'on (nous ou de futurs mainteneurs) ne s'y perde pas.

J’ai documenté ça dans un @moduledoc dans le contrôleur, dis-moi si c’est bien @thbar !

[thbar]

@vdegove ici il aurait été pertinent d'utiliser des doctests, mais on verra plus tard.

[thbar]

Beau travail @vdegove!

La doc sur le module m'a parue claire aussi, merci.

J'ai vérifié les aspects suivants:

• non régression tant fonctionnelle que performance (sauf erreur)

J'ai apporté quelques changements:

• DRY et amélioration (mise en gras, tout en haut de la description) de l'aspect mise en avant du côté expérimental (voir copie d'écran plus bas)
• Config OpenAPISpex pour désactiver le cache en local (sinon il faut redémarrer à chaque tour et c'est pénible)
• Amélioration de la doc pour documenter ce qui se passe en cas de nombre de points excessif

On gagnerait à ajouter des "doctests" autour des fonctions de parsing, @vdegove je te laisse te chauffer dessus sur une prochaine PR si tu veux, c'est un bon exercice !

Copie d'écran du rendu après modification:

[thbar]

@vdegove @AntoineAugusti si vous avez besoin de travailler sur la partie OpenAPI, pensez à décommenter ça que je viens de découvrir car ça fatiguait de redémarrer, c'est très pratique ! (je ne l'ai pas laissé par défaut car pas sûr de l'impact sur le reste en dév, type recompilation lente ou autre etc)