Erreur 400 sur le widget de recherche des extensions pour Openlayers

Bonjour,

Dans mon code javascript j'utilise un composant ol.control.SearchEngine de l'API JS OL. Je suis en 3.4.0-beta4.
Depuis la migration, les appels finissent en 400 car la valeur "location" est affectée au paramètre index et ce n'est pas accepté par le service.
Exemple : https://data.geopf.fr/geocodage/sear...ation&limit=20

Comme c'est un composant ol il n'y a pas la main sur ce paramètre.
Il y a une adaptation à faire ? Je ne trouve rien sur le sujet. Vous n'avez quand même pas migré vers le nouveau service sans tester le composant JS de recherche d'adresse ?
Le paramètre index ne devrait pas avoir pour valeur "address" ou simplement ne pas être présent ?

Sur votre page de doc https://geoservices.ign.fr/documenta...penlayers#1928 dans l'exemple JSFiddle, les appels au service de recherche d'adresse finissent aussi en 400

Bonjour,

comment avez vous généré cette requête ?

Les index possibles sont :
- poi
- address
- parcel

Par exemple :
https://data.geopf.fr/geocodage/sear...x=poi&limit=20
https://data.geopf.fr/geocodage/sear...20&city=nantes


Je n'ai pas vu d'erreur dans les requêtes générées par le widget de recherche via l'exemple JSFiddle cité.

Il faut appuyer sur entrée dans le composant pour lancer la requête de recherche d'adresse. Si on saisit juste des caractères c'est le service d'autocomplétion qui est appelé qui lui est OK. C'est votre composant tout de même.
Pièce jointe 651912

Pièce jointe 651913

Merci pour le rappel, mais je suis au courant que le service d'autocomplétion est appelé lorsque l'on tape des lettres dans la barre de recherche.

Le service de geocodage est appelé principalement quand on passe par le bouton recherche avancée (bouton rouage à droite de la barre), ce que j'ai testé et qui ne génère pas d'erreur à première vue. Il est effectivement également appelé avec le comportement que vous décrivez, en appuyant sur entrée dans la barre de recherche, et il y a un bug. C'était l'objet de ma question précédente.

La prochaine fois, merci d'y répondre simplement, et idéalement de décrire plus précisément les manipulations faites pour reproduire l'erreur, on a un certain nombre de remontées à traiter, et si elles sont correctement décrites dès le début, on évite ce genre d'aller-retours chronophages. Et surtout, merci d'éviter l'ajout une remarque désagréable en fin de réponse, afin que l'on reste dans une discussion constructive.

Cela étant dit, je vais investiguer et corriger le problème, qui devrait être intégré à la prochaine release.

Oubli, corrigé par https://github.com/IGNF/geoportal-ex...f9a126c61d4b26

Sera intégré à la release adaptative définitive (toujours en attente de données sur les services isochrone/itinéraire)


NB : Les messages sur ce bug ont été déplacés dans une discussion dédiée