Closed florimondmanca closed 4 months ago
Comment ça se fait qu'on utilise le libellé et pas le code INSEE ? :thinking:
On utilise le code Insee pour la commune, mais le problème se situe sur le nom de la voie ici (et une voie n'a pas de code unique)
Ah, d'accord. Ca m'étonnait aussi. :sweat_smile:
On ne peut pas se passer de l'API Adresse et requêter directement l'API Géoplateforme ? Eventuellement via l'API dédiée aux besoins d'autocomplétion ?
C'était ce que je me demandais aussi dans la description du ticket
... À plus long terme, on voit que l'API de l'IGN et l'API Adresse diffèrent quelque peu dans le formatage des noms de voies. Et l'API de l'IGN est très "sensible" (pas du tout fuzzy) donc on doit implémenter une forme de "normalisation" nous-mêmes. L'IGN a aussi une API de géocodage. Devrait-on envisager de l'utiliser ? Est-ce que ça réduirait ces "subtiles incompatibilités" ?
Ça serait potentiellement un autre ticket je dirais, pour bien explorer les tenants et aboutissants...
Edit : premier problème que je viens de trouver, l'option terr
qui d'après leur doc accepte un code insee...
"description": "une limitation de la zone de recherche de localisants. Les valeurs acceptés sont METROPOLE, DOMTOM, les codes département et les codes communes (INSEE).",
Elle accepte en fait des codes postaux... Ils mettent d'ailleurs en exemple 75013 qui est le code postal de Paris 13e et pas son code insee (qui est 75113).
On voit aussi que dans le résultat on a le zipcode
mais pas qqc comme le insee_code
.
À l'inverse l'API Adresse permet de filtrer par code insee (et le récupérer dans la réponse si besoin).
Je parlais du service d'autocomplétion de la Géoplateforme pas celui de géocodage qui est celui que tu mentionnais dans le corps du ticket.
Concernant l'API d'autocomplétion (https://data.geopf.fr/geocodage/completion
) :
l'option terr qui d'après leur doc accepte un code insee (...) Elle accepte en fait des codes postaux
Ca pour moi c'est un bug à faire remonter ! ou une incohérence de la doc, mais qu'un tel service s'appuie sur le code postal plutôt que le code commune INSEE me paraît aberrant.
A priori le dépôt est ici : https://github.com/Geoplateforme/gpf-geocodeur
Une prise de contact auprès de Jérôme Desboeufs (via email ou Mattermost beta) serait utile je pense.
Concernant l'API de géocodage (https://data.geopf.fr/geocodage/search
) :
Elle propose bien un paramètre citycode
pour filtrer les résultats par code commune INSEE.
Mais je suppose que si on l'utilise à la place de l'API Adresse, on perdra l'autocomplétion...
Il y a aussi un "Service Géoplateforme de recherche" que je n'ai pas exploré.
Ca pour moi c'est un bug à faire remonter ! ou une incohérence de la doc, mais qu'un tel service s'appuie sur le code postal plutôt que le code commune INSEE me paraît aberrant.
Oui ça me semble être un bug aussi. Je vais ouvrir un ticket pour le signaler et en discuter
Il y a peut-être également un problème avec les apostrophes :
J'ai créé un ticket séparé https://github.com/MTES-MCT/dialog/issues/661 pour la question du remplacement possible de l'API Adresse par l'API autocomplétion de l'IGN
@aureliebaton Oui dans ton screenshot l'apostrophe a l'air d'être spécial ? ՚ (U+055A) vs ' (U+0027) -> Prévoir une normalisation des apostrophes aussi...
@florimondmanca j'ai sélectionné dans la liste qui m'était proposée, mais mon navigateur est en anglais donc c'est sans doute ça le pb ?
@aureliebaton ton problème est résolu par #668
@mmarchois Intéressant : l'apostrophe spéciale était renvoyée par l'API Adresse directement, ça ne provenait pas d'Aurélie
... À plus long terme, on voit que l'API de l'IGN et l'API Adresse diffèrent quelque peu dans le formatage des noms de voies. Et l'API de l'IGN est très "sensible" (pas du tout fuzzy) donc on doit implémenter une forme de "normalisation" nous-mêmes. L'IGN a aussi une API de géocodage. Devrait-on envisager de l'utiliser ? Est-ce que ça réduirait ces "subtiles incompatibilités" ?
Ce sujet va devenir important : il y a des cas qu'on ne peut pas anticiper, comme les différences de liaisons (Rue de Saint-Denis, etc). On va devoir explorer la piste de l'utilisation du service de l'IGN pour faire les deux : autocomplétion et géocodage.
Comportement attendu
Quand on saisit une voie nommée qui peut ou pas contenir un trait d'union, le géocodage réussit dans tous les cas
Comportement réel
Si l'API Adresse renvoie une suggestion ne contenant pas de trait d'union mais que l'API de l'IGN ne connaît que la version avec un trait d'union, le géocodage échoue (erreur "La voie n'existe pas")
Pour reproduire
Contexte supplémentaire
Découvert en faisant la liste #614
Pistes de résolution
On avait eu le même problème avec les accents et on avait pu appliquer un filtre : #595
Une solution pourrait être d'appliquer un filtre pour supprimer tous les traits d'union dans la recherche. En l'occurrence
strReplace('-', '', true)
. Voir Filter function reference (geoserver.org)... À plus long terme, on voit que l'API de l'IGN et l'API Adresse diffèrent quelque peu dans le formatage des noms de voies. Et l'API de l'IGN est très "sensible" (pas du tout fuzzy) donc on doit implémenter une forme de "normalisation" nous-mêmes. L'IGN a aussi une API de géocodage. Devrait-on envisager de l'utiliser ? Est-ce que ça réduirait ces "subtiles incompatibilités" ?