Discussion :

[tybern]

Bonjour,

(ce message avant tout destiné à quelqu'un de l'IGN si à l'écoute)

Je suis en train de migrer une application vers la Géoplateforme.

Je suis très déçu et embarassé par le service de calcul d'altimétrie : par rapport à l'ancien service, les temps de réponses sont assez longs parfois, assez imprévisibles, et surtout, certaines requêtes ont rejetées avec erreur 400, et le message suivant :

Code :

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

{"error": {"code": "BAD_PARAMETER", "description": "'ign_rge_alti_wld' is not an accepted resource."}}

Message tout à fait injustifié évidement.

Il suffit de la relancer, et ça passe, mais ce n'est pas véritablement très "pratique"...

N'y aurait-il pas un serveur mal configuré ?
Comment expliquer les temps de réponses importants ? Y aura-t-il une amélioration à espérer ?

Merci d'avance,

Cordialement,

[elias couppe]

Bonjour,

il y a effectivement un problème identifié et en cours de correction sur les serveurs du service d'altimétrie.

J'essayerai de revenir vers vous sur ce sujet quand le problème sera résolu.

[tybern]

Bonjour,

Merci de votre réponse.

Je vais patienter donc, en espérant que vous pourrez résoudre le problème rapidement et au mieux.

Cela me semble "chaud" cette bascule Geoplateforme non ?

Cordialement,

[tybern]

Bonsoir,

Vous (IGN) avez fait deux interventions sur "geopf", une lundi dernier toute la matinée, et une tout à l'heure à 17h.

Mais je suis au regret de devoir vous signaler que je continue d'avoir des erreurs HTTP 400 en pagaille sur le service altimétrie.
C'est en ce qui me concerne absolument inutilisable en production.

J'ai tout porté sur la geoplateforme sle plus vite possible comme vous l'avez demandé aux développeurs, et je suis dans l'incapacité de passer ma version modifiée en production.

Concernant le service de tuiles WMTS, les problèmes sont plus rares, mais toujours aussi des erreurs HTTP 404.

Cordialement,

[jeanluc35]

Bonjour,

J'ai également un problème avec le service altimétire, c'est sans doute le même que tybern.
Mes requètes de la forme : https://data.geopf.fr/altimetrie/1.0..._alti_wld&lon= { lon } &lat= { lat } &zonly=true, sont systématiquement en erreur :

{
"error": {
"code": "BAD_PARAMETER",
"description": "'ign_rge_alti_wld' is not an accepted resource."
}
}

Cordialement,

Jean-Luc

[tybern]

Bonsoir,

Oui, nous avons les mêmes problèmes, et malgré les arrêts de services pour optimisation, je ne vois pas d'améliorations...
Je ne peux pas utiliser l'altimétrie en l'état, on vient de me dire aujourd'hui que la diffusion de "Plan J+1" ne serait peut-être pas prête le 15 mars à la fermeture du service actuel.
C'est moins fréquent, mais j'ai toujours des erreurs 404 sur les services WMTS raster.
Je reçois régulièrement des mails de l'IGN me disant de migrer le plus vite possible, mais en même temps, je vois que Geoportail, IGNrando, Cirkwi, et beaucoup d'autres n'ont pas migré...
Nous sommes le 25 janvier alors qu'initialement l'ancien service devait s'arrêter le 15 janvier.
Le message de l'IGN est que ça a été prolongé pour "nous" laisser un peu de temps, moi, j'étais prêt le 15 décembre alors que les propres sites IGN (Geoportail, IGNrando, MaCarte, ...) n'ont pas migré à ce jour.
Si ça ne tient pas la charge actuellement, que va-t-il se passer quand Geoportail va consommer ?

Je dois bien dire que je n'y comprends plus rien !

Est-ce que le nouvel hébergeur (OVH) est en cause (ça ne m'étonnerait qu'à moitié...) ?

Cordialement,

[elias couppe]

Un correctif pour améliorer la stabilité du service d'altimétrie de la Géoplateforme a été déployé ce jour.

Normalement, la situation est nominale.

N'hésitez pas à nous signaler si vous constatez toujours des instabilités sur le service d'alti.

[tybern]

Bonjour,

Effectivement, j'ai testé hier soir, et je n'avais plus d'erreurs sur l'altimétrie.
Mais je n'ai fait que des essais courts (requêtes d'un seul point).

Je vais continuer à surveiller, mais c'est plutôt une bonne nouvelle !

Qu'elle est désormais la taille limite pour le nombre de points traitables sur un appel (il était devenu très faible) ?

Cordialement,

[elias couppe]

D'après la documentation (https://geoservices.ign.fr/documenta...timetrie#72673), 5000 points. Mais nous déconseillons d'en mettre autant.

[tybern]

Rebonjour,

Avec le service actuel (ancien), je mettais maximum 500 points en GET, et 4000 en POST.
La limite en GET est de toute façon imposée par la longueur de la requête acceptable par les navigateurs et serveurs.

Avec geopf, je mettais 500 maximum dans les deux cas (avant de revenir en arrière à l'ancien service).

Je vais laisser 500 en GET, et sans doute une valeur aux alentours de 2000 ou 3000 en POST.
Comme c'est dans du javascript, et que je dois resérialiser les réponses qui arrivent dans le désordre, moins j'ai de segments, mieux c'est pour moi.

Vous pensez que c'est raisonnable ?

Cordialement,

[azarzelli]

Bonjour,

Oui, ça me semble raisonnable.

Cordialement,

[tybern]

OK, merci.

Je constate aussi aujourd'hui une quasi disparition des erreurs 404 sur les requêtes WMTS raster.
Une bonne nouvelle également si ce correctif concernait aussi ce service.

Cordialement,

[tybern]

Bonsoir,

Je viens de rebasculer toutes mes requêtes altimétrie sur la géoplateforme :
- le service est stable, je n'ai pas d'erreur ;
- mais, par rapport au précédent service REST, j'ai la très nette impression que le temps de réponse est notablement pluslong, surtout avec des requêtes importantes.
en particulier, si je demande 2000 points (donné ci-dessus comme étant une valeur raisonnable), le temps de réponse est véritablement long (5 à 10 secondes).
Cela fonctionne mieux si je fais plutôt 4 requêtes de 500 points successives.

Est-ce actuellement la performance nominale de ce nouveau service ou peut-on espérer des améliorations ?

Cordialement,

[jp4810]

Bonjour,
J'ai fait le même constat : les temps de réponse pour l'altimétrie sont dégradés par rapport à ce qu'ils étaient...
J'ai réalisé la semaine dernière un comparatif de requêtes GET altimétriques sur l'ancienne infrastructure et sur la géoplateforme pour les mêmes coordonnées géographiques (162 points).

J'ai exécuté 10 fois la requête pour chaque plateforme.

Géoplateforme

Temps de réponse moyen : 1,153 s - Plus lent : 2,57 s - Plus rapide : 584 ms

Ancienne infrastructure

Temps de réponse moyen : 242 ms - Plus lent : 487 ms - Plus rapide : 144 ms

La géoplateforme est donc en moyenne quasiment 5 fois plus lente que l'ancienne infrastructure pour cette requête.

[elias couppe]

Bonjour,

il y a effectivement des soucis notables de performances sur ce service et qui sont en visibilité de notre côté.

[tybern]

Bonjour,

Je m'aperçois qu'il y a des différences notables concernant la réponse aux requêtes altimétrique sur l'estran, ou proche de l'estran sur la cote.

Par exemple, voici le résultat d'une même requête (un seul point que j'ai extrais d'une trace passant par là, en GET) sur wxs :

Code :

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

https://wxs.ign.fr/calcul/alti/rest/elevationLine.json?zonly=true&indent=false&sampling=1&lon=-2.42585598&lat=48.65177970

réponse :

Code :

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

{"elevations": [{"lon": -2.42585598,"lat": 48.6517797,"z": 0.0,"acc": 2.5}]}

... et sur geopf

Code :

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

https://data.geopf.fr/altimetrie/1.0/calcul/alti/rest/elevation.json?zonly=false&resource=ign_rge_alti_wld&indent=false&sampling=1&lon=-2.42585598&lat=48.65177970

réponse :

Code :

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

{"elevations": [{"lon": -2.42585598, "lat": 48.6517797, "z": -33509.54, "acc": "Variable suivant la source de mesure"}]}

-33509m, c'est assez excessif...

Pour donner une idée du lieu :



Le point est sur l'isthme d'une presqu'île.

Il semble qu'il y a un problème avec la source de données en bordure de côtes non ?

Cordialement,

[tybern]

Bonjour,

Encore moi... et à nouveau questions à l'IGN :

Aujourd'hui, les temps de réponses pour l'altimétrie sont catastrophiques... souvent 10s à 15s, j'ai même eu 31s pour une requête de 61 points seulement.

A ce jour, l'ancien service REST sur wxs est toujours accessible : va-t-il le rester après le 15 mars ?
Et pourrait-il rester accessible tant que le nouveau service ne fonctionne pas correctement ?

Question encore plus complexe : pouvez-vous envisager de revenir à l'API REST sur Geopf, cette API étant de toute évidence plus performante que celle du nouveau service ?

Cordialement,

[elias couppe]

Bonjour,

nous sommes conscients du caractère insatisfaisant des performances du nouveau service d'altimétrie, et travaillons pour résoudre les problèmes.

Notre prestataire a prévu une mise en production aujourd'hui dans l'après midi qui est censée améliorer sensiblement les performances du service.

A ce jour et à ma connaissance, il n'est malheureusement pas prévu (ni possible) de prolonger la durée de vie de l'ancien service.


En nous excusant évidemment pour la gêne occasionnée.

[jp4810]

Notre prestataire a prévu une mise en production aujourd'hui dans l'après midi qui est censée améliorer sensiblement les performances du service.

Bonjour,

Je ne constate pas d'amélioration de mon côté... chaque requête altimétrique nécessite plusieurs secondes sur la géoplateforme ; quasiment 10 fois plus lent qu'avec les anciens géoservices.

Jean-Philippe

[tybern]

Bonjour,

Je viens de faire quelques mesures, voir si l'opération indiquée a amélioré les choses : pour des requêtes de quelques dizaines de points maxi, je tournais aux alentours de 1s à 3s de délai.
J'ai groupé une demande pour 4700 points, découpée en requêtes de 500 points, tout envoyé en même temps (je dois avouer que je ne sais plus s'il faut grouper les requêtes, ou au contraire les segmenter pour que ce soit plus efficace...).
Le résultat est sur cette capture d'écran :

Là, on comprend que ça provoque une très sérieuse dégradation avec une des requête qui a attendu plus de 10 secondes.
On voit sur cette capture que la requête d'itinéraire préalable n'a demandé que 0.2s, ça, ça fonctionne très bien.

C'est assez déconcertant de voir un service qui fonctionnait se mettre à ne plus être performant à l'occasion d'une opération dont on avait compris que c'était pour améliorer les services non ?

Cordialement,