Erreur : general.tileMatrixSets is undefined dans patch_autoconf.js

Bonjour,

J'utilise encore la version 2 de l'API ; j'ai installé le script patch_autoconf.js pour éviter l'erreur B.supportedCRS is undefined dans GeoportalExtended.js
Depuis hier, j'ai l'erreur : general.tileMatrixSets is undefined dans patch_autoconf.js
Cependant cette erreur cette erreur ne se produit que de façon intermittente.

Y a-t-il quelque chose à faire (à part passer à la version 3) ?
Merci d'avance.

Cordialement

Michel Delord

PS : j'ai essayé de supprimer l'appel à patch_autoconf.js mais je retombe sur l'erreur B.supportedCRS is undefined

Bonjour,
je suis dans la même situation depuis hier.
Je suis entrain de recoder mon application avec l'API v3, mais je ne suis pas encore tout à fait prêt.
Sur son blog (https://geoservices.ign.fr/blog/2019...s_fin2019.html), l'IGN annonce l'arrêt de l’api geoportail javascript v2 le 27 novembre 2019.
Il semble que des événements techniques non prévus soient apparus, quelqu'un serait capable de faire un nouveau patch ?

Bonjour,
Est-ce que ce ne serait pas lié au changement des URI dans le GetCapabilities des services qui empêche de parser le XML ?

Je n'utilise pas cette librairie, mais je vois sur ce dépôt : https://github.com/opalesurfcasting/.../v1_0_0.js#L31

Code:

---

1 2 3 4 5

namespaces: { ows: "http://www.opengis.net/ows/1.1", wmts: "http://www.opengis.net/wmts/1.0", xlink: "http://www.w3.org/1999/xlink" },

---

Or dans le GetCapabilities, on a désormais ces URI en https :

Code:

---

1 2 3 4 5

<Capabilities xmlns="https://www.opengis.net/wmts/1.0" xmlns:ows="https://www.opengis.net/ows/1.1" xmlns:link="https://www.w3.org/1999/xlink" ...

---

donc si le parser utilise les URI en http, il ne pourra plus trouver les éléments attendus dans le capabilities et des variables se retrouvent "undefined".

J'ai eu ce problème depuis lundi avec une autre librairie, je viens de faire un nouveau message à ce sujet.

En attendant un retour de l'IGN, vous pouvez toujours essayer de changer la liste des namespaces dans votre JS pour passer en HTTPS et voir si ça règle le problème.

Cordialement,

Matthieu

Bonjour,

En effet, les URI des namespaces dans les GetCapabilities sont désormais en HTTPS, c'est une erreur, et c'est probablement la cause des problèmes que vous rencontrez (cf. https://www.developpez.net/forums/d2...services-wmts/)

Cela devrait être corrigé dans la journée (retour aux urls en HTTP), nous vous tiendrons informés.

Nous nous excusons pour le dérangement occasionné.

Bonjour,

Avez-vous du nouveau sur ce sujet ? Je suis également bloqué avec ce problème. Les namespaces passeront-ils en HTTPS le 27 novembre 2019 ?

Bonjour,

Le problème devrait finalement être corrigé mardi matin.

Cela n'est pas lié au passage en HTTPS des services le 4 décembre -> ces urls (namespaces dans la balise d'en-tête des réponses autoconf ou GetCapabilities) devraient rester en HTTP.

(d'ailleurs, dans votre message vous faites allusion à la date du 27 novembre : cette date correspond à l'arrêt de l'API JavaScript v2, le passage en HTTPS est prévu lui pour le 4 décembre).

Bonjour,

Nous sommes mardi après midi, et il semble y avoir toujours le problème.
La correction a-t-elle été décalée?

Merci

Bonjour,

Non, le déploiement de la correction est bien en cours, mais il se peut que le navigateur ait mis en cache les réponses des requêtes, donc que vous visualisiez toujours les anciennes réponses (avec les urls en https).

De mon côté j'arrive à visualiser la correction, mais en vidant bien mon cache. L'ajout d'un paramètre supplémentaire, inutile, dans la requête permet de tester en forçant le rechargement de la réponse et donc de visualiser la modification.
Par exemple avec l'url suivante : https://wxs.ign.fr/choisirgeoportail...onf?param=test -> on doit avoir, dans la première balise :

Code:

---

xsi:schemaLocation="http://www.opengis.net/context context.xsd"

---

(et non plus "https...")

Bonne journée,

Laurane

Bonjour,

Merci pour votre réponse.
J'attends encore celle du support.... :(

En effet, cela fonctionne maintenant.
Pour ma part, c'était le WMS qui posait problème depuis mardi 15/10

Merci
Bonne journée

Bonjour,

De mon côté je récupère toujours les namespace en https :

Code:

---

<ViewContext xmlns=\"https://www.opengis.net/context\" xmlns:gpp=\"https://api.ign.fr/geoportail\" xmlns:ows=\"https://www.opengis.net/ows/2.0\" xmlns:sld=\"https://www.opengis.net/sld\" xmlns:wmts=\"https://www.opengis.net/wmts/1.0\" xmlns:xlink=\"https://www.w3.org/1999/xlink\" xmlns:xsi=\"https://www.w3.org/2001/XMLSchema-instance\" id=\"autoConf\" version=\"1.1.0\" xsi:schemaLocation=\"https://www.opengis.net/context context.xsd\">

---

Le correctif est bien entièrement déployé ?

Oui, je confirme que le correctif est bien déployé, mais comme je l'évoquais précédemment, la réponse aux requêtes est probablement encore dans le cache du navigateur, avec les namespaces en https.

Pour ma part, j'ai bien le namespace en http, mais l'erreur est toujours là. (Il me semblait que le problème venait plus de la structure du XML que du namespace...)

Pièce jointe 512430

Pièce jointe 512433

L'erreur est en effet toujours là. Si l'url est bien revenue en http sur le XML, la version appelée par l'API v2 ajoute les paramètres ?output=json&callback=OpenLayers.Protocol.Script.registry.regId1 et celle-ci a toujours le souci (même sans cache coté navigateur) :

Pièce jointe 512471

Peut-être un cache au niveau de l'IGN ?

Le service d'autoconf renvoie toujours du https :

Code:

---

<?xml version=\"1.0\" encoding=\"UTF-8\"?><ViewContext xmlns=\"https://www.opengis.net/context\" xmlns:gpp=\"https://api.ign.fr/geoportail\" xmlns:ows=\"https://www.opengis.net/ows/2.0\" xmlns:sld=\"https://www.opengis.net/sld\" xmlns:wmts=\"https://www.opengis.net/wmts/1.0\" xmlns:xlink=\"https://www.w3.org/1999/xlink\" xmlns:xsi=\"https://www.w3.org/2001/XMLSchema-instance\" id=\"autoConf\" version=\"1.1.0\" xsi:schemaLocation=\"https://www.opengis.net/context context.xsd\">

---

Tandis que les autres services (ex: recherche d'adresse) renvoient du http :

Code:

---

<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?><XLS version=\"1.2\" xsi:schemaLocation=\"http://wxs.ign.fr/schemas/olsAll.xsd\" xmlns:xls=\"http://www.opengis.net/xls\" xmlns=\"http://www.opengis.net/xls\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:xlsext=\"http://www.opengis.net/xlsext\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">

---

Du coup même en modifiant les namespaces directement dans le code de l'API JS pour les mettre en https certaines fonctionnalités ne marchent pas car elles renvoient du http

Effectivement, il est étrange que les urls de l'autoconf appelée par l'API v2 soient toujours en https, il s'agit très certainement de cache, on ne sait pas trop à quel niveau...

Si le problème vient bien du parsing de l'autoconf, une éventuelle solution (très temporaire, jusqu'en décembre) serait de :
- mettre l'autoconf en local (url qui ne sera plus accessible en 2020)
- editer l'autoconf pour remplacer le https par du http

C'est une piste, nous n'avons pas la certitude que cela fonctionnera. L'API v2 étant désormais largement dépréciée, nous n'avons plus vraiment les outils pour assurer son support.
La meilleure solution reste de migrer sur l'API v3 ;)

Bonjour,

Merci pour ce retour.

J'ai contourné le problème en passant uniquement certains namespaces en https.
Qu'entendez-vous par "url qui ne sera plus accessible en 2020" ?
L'url http://wxs.ign.fr/-key-/autoconf/?ou...egistry.regId1 ne marchera plus ? Sous quelle date précisément ?

De mon côté j'ai également contourné en remplaçant certaines occurrences de `https` par `http`, en ajoutant ceci dans le `geoportal-patch-autoconf.js` :

Pièce jointe 512886

C'est moche, minimaliste (ça ne gère aucun cas d'erreur tel que géré dans la code original), mais ça fonctionne (du moins, jusqu'à là mise hors ligne définitive de la v2).
C'est largement améliorable (try/catch, regexp, remplacement plus sélectif), mais j'ai pas forcement de temps à y consacrer pour le moment.

Si certains veulent échanger sur le patch en question, il y a une pull-request ici : https://github.com/mabhub/geoportal-...utoconf/pull/1

Citation:

---

Envoyé par Guiguiii

Bonjour,

Merci pour ce retour.

J'ai contourné le problème en passant uniquement certains namespaces en https.
Qu'entendez-vous par "url qui ne sera plus accessible en 2020" ?
L'url http://wxs.ign.fr/-key-/autoconf/?ou...egistry.regId1 ne marchera plus ? Sous quelle date précisément ?

---

Bonjour,

je mentionnais l'url où se trouve la documentation de l'APIv2 (depot.ign.fr).
Nos services ne fonctionneront de toute manière plus avec l'APIv2 à partir de début décembre.

Je compte bien migrer vers la V3 en début d'année prochaine, mais en attendant j'ai embarqué le code JS de l'API sur mon serveur pour que ça puisse continuer de fonctionner, comme mentionné dans d'autres discussions. Les webservices devraient bien continuer de fonctionner de la même manière même après la fermeture du site de l'API V2 ?

Les webservices continueront de fonctionner, mais en plus du passage forcé en https, les ressources en ligne utilisées par l'API v2 ne seront plus disponibles. Il faudra donc tout rapatrier en local, mais sans aucune garantie qu'il n'y aura aucun autre effet de bord, comme celui sujet de ce fil de discussion...