Closed florimondmanca closed 6 months ago
Comme discuté aujourd'hui, la décision d'internaliser l'hébergement de la BD TOPO a été prise. Une fois qu'on aura un système iso avec celui utilisé actuellement (service Géoplateforme de requêtage et de récupération de géométries tel qu'utilisé par #536 et #571), il faudra également trouver un système pour remplacer l'API Adresse comme discuté sur #661, par exemple qui puisse fonctionner avec l'API Géoplateforme d'autocomplétion.
Par ailleurs la solution doit être envisagée dans le contexte du #518 au global et notamment prendre en compte l'exploration sur les "tronçons de route" https://github.com/MTES-MCT/dialog/issues/518#issuecomment-1982070020
Comportement attendu
Quand on géocode des voies nommées ou autres données en passant par l'API WFS de l'IGN (https://data.geopf.fr/wfs/ows), l'API répond
Ceci devient d'autant plus important à mesure que l'on accroit notre dépendance au géocodage à partir des données IGN
Actuellement : géocodage de voie nommée entière pour le seul cas où la localisation ne concerne que la voie entière
Quand #669 sera mergé (mis en attente pour le moment) : géocodage de voie nommée entière pour toutes les localisations de type "voie nommée", qu'elles soient entières ou partielles (numéros de début ou de fin)
Comportement réel
Aujourd'hui (11 mars 2024) je considère que l'API IGN est inutilisable, car je rencontre :
Auparavant je n'avais que des lenteurs mais aujourd'hui c'est vraiment la catastrophe.
Pour reproduire
Contexte supplémentaire
Escaladé car j'allais merger #669 qui accroissait notre dépendance à l'API IGN, mais la qualité de service de cette API ne semble pas durable
Pistes de résolution
L'option principale que je vois : Héberger et s'interfacer directement avec la BD TOPO
L'approche envisagée est détaillée dans ce document d'architecture (ADR) : https://github.com/MTES-MCT/dialog/blob/feat/bdtopo/docs/adr/008_bdtopo.md