Discussion :

[sebastien_2]

Bonjour,

Nous sommes confrontés à une erreur JavaScript dans une application Web qui fonctionnait correctement jusqu'à récemment (le problème date du 30 janvier apparemment), alors que nous n'avons rien changé.
Cette erreur empêche l'application de fonctionner (complètement).

L'erreur se produit dans GeoportalExtended.js qui est chargé via https://api.ign.fr/geoportail/api/js...talExtended.js

Firefox indique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TypeError: B.supportedCRS is undefined

dans GeoportalExtended.js:138:2395290

Avec le debugger, je vois plus précisément que l'erreur se produit sur l'instruction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var aB = B.supportedCRS = B.supportedCRS.replace(/epsg/, 'EPSG');

Chrome indique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Uncaught TypeError: Cannot read property 'replace' of undefined
    at Function.Geoportal.Catalogue.completeConfiguration (GeoportalExtended.js:138)
    at Geoportal.GeoRMHandler.parseAutoConf (GeoportalExtended.js:138)
    at GeoportalExtended.js:138
    at initialize.handleResponse (GeoportalExtended.js:138)
    at initialize.handleRead (GeoportalExtended.js:138)
    at initialize.<anonymous> (GeoportalExtended.js:138)
    at Object.<anonymous> (GeoportalExtended.js:138)
    at Object.b.registry.(/anonymous function) (https://api.ign.fr/geoportail/api/js/2.1.2/GeoportalExtended.js:138:1475728)
    at ?output=json&callback=OpenLayers.Protocol.Script.registry.regId1:1

Pour la dernière ligne de la trace des appels, cela vient d'une URL du style http://wxs.ign.fr/CLE/autoconf/?outp...egistry.regId1
Cette URL renvoie bien des données (avec une vraie clé d'API, bien sûr).

Est-ce que quelqu'un d'autre rencontre le même problème ?

Est-ce que ça serait lié à la migration qui a eu lieu le 30 janvier ? (https://geoservices.ign.fr/blog/2019...n-annonce.html)

[mga_geo]

Bonjour,
J'ai effectivement le même problème sur http://ao35.free.fr/geoportail/bzh.html
La version migrée n'est probablement pas la bonne !
Marc

[IGNC_XT]

@mga_geo
Est-ce qu'en utilisant l'autoconf en local en suivant les instructions ici : https://depot.ign.fr/geoportail/api/...tion_des_APIs; avec le fichier ci-joint correspondant à votre clé, cela fonctionne?
A dezipper

Après je tiens à signaler que l'api V2.1.2 est déprécié depuis 2 ans, il y aeu des informations sur le blog géoservices, des tutoriels proposés, une journée entière consacrée au sujet.
Passer aux nouvelles API est la solution à réellement envisager

[michelD13]

Bonjour,

Depuis le 30 janvier, j'ai le même problème que sebastien_2 : http://gpx2tdm.free.fr/. Je sais que la version 2 est dépréciée mais je l'apprécie car elle offre des possibilités qui ont disparu dans la version 3 (possibilité de supprimer des trkpt individuellement, possibilité d'enregistrer en gpx...).

Comme conseillé, j'ai rapatrié en local autoconf.js mais le message d'erreur reste le même :
- avec Chromium :

Uncaught TypeError: Cannot read property 'replace' of undefined
at Function.Geoportal.Catalogue.completeConfiguration (GeoportalExtended.js:138)
at Geoportal.GeoRMHandler.parseAutoConf (GeoportalExtended.js:138)
at GeoportalExtended.js:138
at initialize.handleResponse (GeoportalExtended.js:138)
at initialize.handleRead (GeoportalExtended.js:138)
at initialize.<anonymous> (GeoportalExtended.js:138)
at Object.<anonymous> (GeoportalExtended.js:138)
at Object.b.registry.(anonymous function) (http://gpx2tdm.free.fr/js/GeoportalE...js:138:1475728)
at autoconf_free.js:1

- avec Firefox :

TypeError: B.supportedCRS is undefined[En savoir plus] GeoportalExtended.js:138:2395290
completeConfiguration http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 parseAutoConf http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 bind http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 handleResponse http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 handleRead http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 c http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 bind http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 <anonyme> http://gpx2tdm.free.fr/js/GeoportalExtended.js:138 <anonyme> http://gpx2tdm.free.fr/js/autoconf_free.js:1

​
L'application fonctionnait parfaitement depuis des années. Peut-on espérer que le retour à la normale après la migration résoudra le problème ?

Cordialement

[bretus]

Bonjour,

Nous avons rencontré le problème sur un site qui est utilise encore l'API géoportail V2 (plus maintenue depuis 2017 de mémoire et archivée ici : https://github.com/opalesurfcasting/api-geoportail-v2)

Le problème semble être au niveau de la lecture d'une partie des informations de l'autoconf. J'ignore ce qui le provoque (peut-être un schéma XML qui est passé de http à https) et si un correctif sera apporté.

En attendant de migrer sur la nouvelle version de l'API, nous avons réussi à patcher avec le script suivant :

https://github.com/mborne/geoportal-...ch-autoconf.js

Vous pouvez tenter de le télécharger et l'inclure juste après "Geoportal.js" (ou "GeoportalExtended.js")?

[michelD13]

Merci bretus.
Votre patch m'a sauvé la vie car j'étais assailli par les plaintes des utilisateurs !
Il serait bon de le communiquer aux responsables de la page :
https://geoservices.ign.fr/documenta...hage-base.html
Ils pourraient ainsi retrouver l'affichage de la carte !
Cordialement

[mga_geo]

Merci @bretus
Je viens de mettre en place le patch et effectivement cela résout le problème.

@IGNC_XT
Migrer une application n'est pas toujours simple, j'ai l'impression que du côté IGN vous donnez pas mal.
Faire migrer des utilisateurs est encore moins simple ...

J'ai au moins une application non migrée qui fonctionne encore car elle est avec de l'autoconf local.

La page bzh.html utilise Geoportal.load avec les paramètres layersOptions, overlays, onView ...
Sur la page de migration vers le sdk https://geoservices.ign.fr/documenta...hage-base.html le lien vers GP.Map.load() devrait être migré : http 404
Après remplacement des bibliothèques js et css, j'ai une erreur J'ai une erreur ReferenceError: Proj4js is not defined, il va falloir que je creuse un peu plus.

[Tourneboule0]

Merci @bretus
J'avais le même pb que nombre d'utilisateur de la V2 et votre patch l'a résolu.
Je sais très bien que cette version est obsolète mais tout le monde n'a pas obligatoirement l'envie et le temps d'effectuer la migration vers la V3, alors que l'on est satisfait de la V2, et qu'à titre personnel je trouve les exemples de l'ign pour la dernière mouture trop succincts (voir les petits développements sur www.yadugaz07.com dans les pages VTT).
Cordialement

[sebastien_2]

Aujourd'hui, c'est l'URL d'autoconf qui semble fonctionner aléatoirement. Parfois (souvent?) elle met 120 secondes à répondre, et ne renvoie que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

OpenLayers.Protocol.Script.registry.regId1({"http":{"status":504,"error":"<html><head><title>504 Gateway Time-out</title></head><body bgcolor=\"white\"><center><h1>504 Gateway Time-out</h1></center><hr><center>nginx</center></body></html>"}, "xml":null})

Ce qui n'est évidemment pas la réponse attendue.

Du coup, j'ai dû mettre l'autoconf en local. Ce qui n'est pas idéal pour nous, la clé d'API n'étant pas la même en dev, recette et prod. Enfin bref.



Par contre, le patch de bretus fonctionne. Merci!

[IGNC_XT]

Bonjour,
Pour le suivi (pour ceux qui répondent comme ceux qui lisent), @sebastien_2 n'hésitez pas à ouvrir un autre ticket.
Oui l'autoconf pose problème, c'est connu et signalé par billets de blogs. C'est pour cela que je recommandais de mettre l'autoconf en local peu importe l'api ol utilisée.

[fabcg]

Bonjour,

je souhaitais apporter ma pierre à l'édifice en proposant une autre solution au même problème (c'est pourquoi je l'ai ajoutée à cette même discussion..?)


Si l'url 'http://wxs.ign.fr/autoconf/$key$/' ne fonctionne pas, en revanche, les url

'http://gpp3-wxs.ign.fr/CLEF/autoconf/?keys='+maLicenceIgn
et
'http://gpp3-wxs.ign.fr/' + maLicenceIgn + '/autoconf/'

répondent correctement en http ou https.


En attendant de migrer aux nouvelles extensions...

Cordialement.

[IGNC_XT]

Si l'url 'http://wxs.ign.fr/autoconf/$key$/' ne fonctionne pas, en revanche, les url

'http://gpp3-wxs.ign.fr/CLEF/autoconf/?keys='+maLicenceIgn
et
'http://gpp3-wxs.ign.fr/' + maLicenceIgn + '/autoconf/'

répondent correctement en http ou https.

Cette solution est à vos risques et périls... En effet, cette URL est amenée à fermer sans aucun préavis et a fortiori aucune garantie de service et aucune support ne seront assurés...

Vous pouvez éventuellement y récupérer la réponse pour l'enregistrer en fichier autoconf.js et l'utiliser en local suivant les conseils donnés sur la doc du site geoservices.ign.fr
Par exemple pour le SDK : https://geoservices.ign.fr/documenta...uration-locale
et bénéficier aussi de l'avantage d'améliorer le temps de chargement.

PAr contre si vous modifiez les paramètres de la clé, il faudra penser à mettre à jour le fichier autoconf en local...

[tmtisfree]

@mga_geo
Est-ce qu'en utilisant l'autoconf en local en suivant les instructions ici : https://depot.ign.fr/geoportail/api/...tion_des_APIs; avec le fichier ci-joint correspondant à votre clé, cela fonctionne?
A dezipper

Après je tiens à signaler que l'api V2.1.2 est déprécié depuis 2 ans, il y aeu des informations sur le blog géoservices, des tutoriels proposés, une journée entière consacrée au sujet.
Passer aux nouvelles API est la solution à réellement envisager

Bonjour,

Comme il n'y a pas eu de réponse claire à votre question, j'y répond : non, l'autoconfig en local ne résout pas le problème.

Je voudrais insister aussi, comme d'autres, qu'il n'est pas toujours envisageable ou même possible de migrer vers une version d'API supérieure pour de multiples (et bonnes) raisons.

Aussi il serait dans l'intérêt des utilisateurs que l'ultime version majeure d'une API soit « sanctuarisée » en terme d'accès aux services, et que cela figure dans la politique de l'IGN.

[fabifabo]

@bretus : un grand merci pour ce patch tout simplement magique !

[nikownm7]

Bonjour,

Depuis que j'ai passé mon pro-logiciel en https j'ai les mêmes erreurs lorsque celui-ci tente d'aller afficher les données géographique des adresses que je lui donne.

Pourrais-je savoir où installer le patch précisément ? (côté serveur / client ?)

Je vous remercie d'avance.

Cordialement.