Discussion :

[ChameleonScales]

Bonjour,
Je vois qu'il y a des discussions un peu similaires mais je n'en ai trouvé aucune sur ce problème précis.

Je viens de découvrir que selon le nombre de points listés dans une requête altimétrique (api REST, script elevation.json), les mêmes points peuvent retourner des résultats différents. Dans mes quelques tests, l'écart du résultat varie de quelques centimètres à une trentaine de mètres.

Vous trouverez en pièce jointe un tableau montrant les résultats de mes tests et les données permettant de les reproduire, disponible en 2 formats:

• LibreOffice : bug-requetes-alti-ign.ods
• ou Microsoft Excel : bug-requetes-alti-ign.xlsx

J'ai utilisé 2 lots de 49 points, l'un éloigné des côtes et l'autre en bordure des côtes bretonnes. Pour chaque lot, j'ai inclus une url de requête d'altitudes.
Une colonne montre les altitudes retournées par cette url et une autre montre celles obtenues en divisant les requêtes par blocs d'environ 7-8 points.

Sur la totalité des points, il y a des différences d'altitudes entre la requête unique et les requêtes divisées.
Pour la plupart, l'écart est de quelques centimètres ou décimètres, mais pour certains il est de plusieurs mètres.

Pourriez-vous m'expliquer d'où vient cette différence? S'agit-il d'un bug ou d'une limitation de l'outil ? Au quel cas, existe-t-il un type de requête plus fiable ?

Merci par avance.

[azarzelli]

Bonjour,

Le comportement observé est le comportement normal du service. Plus précisément il s'agit d'un mécanisme de préservation du service lui permettant de mieux supporter la charge : plus une requête contient de points éloignés entre eux, plus le service doit charger de tuiles de données pour obtenir les altitudes correspondantes. Au-delà d'un certain seuil (30 tuiles) il est paramétré pour ne pas charger les tuiles de haute résolution (qui représentent alors un trop gros volume) mais le niveau au-dessus (2m/pixel), et recommence le process jusqu'à trouver un niveau adapté. Il envoie alors une réponse interpolée à partir de ces données de moindre résolution.

C'est ce qui arrive dans les exemples fournis : la requête à 8 points revient avec la valeur haute résolution (1m), alors que la requête à 49 points est trop dispersée et la réponse est donc une interpolation sur des données de résolution inférieure.

La trace de ce comportement est la modification de la valeur du champ "acc". Nous avons pour projet d'expliciter dans ce champ le niveau de pyramide utilisé pour répondre à la requête.

Cordialement,

[ChameleonScales]

Merci pour votre réponse.
Je ne vois pas de mention de cette limitation sur la page de documentation du service. Pourtant il me paraît important de l'indiquer afin que les utilisateurs qui ont besoin d'une précision maximale puissent adapter leurs requêtes.

Pourriez-vous me préciser si lors d'une requête, le script charge toutes les tuiles contenues dans la boîte englobante des points ou s'il charge seulement les tuiles sur lesquelles se trouvent des points ?
Dans le premier cas, 2 points suffiraient à dépasser le seuil de 30 tuiles, du moment que leur boîte englobante en contient plus de 30, tandis que dans le 2e cas, il faudrait un minimum de 31 points pour dépasser le seuil, quel que soit leur éloignement.

Pourriez-vous aussi me préciser la taille d'une tuile de haute résolution afin que nous puissions estimer comment diviser nos requêtes ? Bien entendu, pour être exact, il faudrait connaître le positionnement des tuiles, mais si nous pouvons déjà faire une estimation approximative, cela nous permettrait d'éviter de dépasser le seuil.

[azarzelli]

Chaque tuile fait 256*256 pixels, donc 256m de côté puisque le RGEAlti a une résolution de 1m. A noter que le service peut tout à fait charger des tuiles disjointes, il ne charge que ce dont il a besoin : il est possible dex demander un point à Brest et l'autre à Nice, ça ne fera quand même que 2 tuiles à charger.

[ChameleonScales]

Parfait, merci pour ces clarifications.