Discussion :

[Max_B]

Pour les éditeurs de logiciels (iPhiGéNie) qui attaquent directement les fluxs WMSC, la migration de juillet s'avère beaucoup plus lourde que prévu. Il ne s'agit pas seulement de modifications de protocoles mais d'un changement de toute la structure des données graphiques.

On change de projection, donc de cordonnées internes; on change aussi le référencement des tuiles pour adopter une pyramide standard. Pour le moment, nous n'avons aucune documentation précise sur ces points. Et le délai est bien court si les services WMSC coupent au 2 juillet

Quelques questions à réponse simple pour préparer le boulot:

1. La pyramide de tuiles est de type TMS ou Google (index y inversé) ?
2. Cette pyramide commence au sommet par une tuile globale pour le globe, et donc les résolutions de chaque couche ne sont plus les même qu'actuellement et ne sont plus non plus des valeurs "rondes" (ex. 4,777m/px au zoom 15) ?
3. Si la réponse à la question 2 est oui, il n'y a donc aucune compatibilité entre les tuiles actuelles et les futures, pas seulement par déformation de projection mais aussi par changement de résolution ?
4. Concernant un autre service, OpenLS: La bascule de juillet changera aussi de version de protocole ?
5. Si oui, le nouveau sera t'il compatible ascendant sur les réponse XML ? C'est à dire que les données déjà gérées et retournées par le protocole actuel seront retournées dans les même éléments XML ?

Je sais que Didier et toute l'équipe sont bien occupés mais quelques infos aideraient.

[dgrichard]

Pour les éditeurs de logiciels (iPhiGéNie) qui attaquent directement les fluxs WMSC, la migration de juillet s'avère beaucoup plus lourde que prévu. Il ne s'agit pas seulement de modifications de protocoles mais d'un changement de toute la structure des données graphiques.

On change de projection, donc de cordonnées internes; on change aussi le référencement des tuiles pour adopter une pyramide standard. Pour le moment, nous n'avons aucune documentation précise sur ces points. Et le délai est bien court si les services WMSC coupent au 2 juillet

Je te trouve légèrement "pushy" ... tu as rencontré l'équipe dernièrement et nous t'avons promis de la documentation pour bientôt ... Ce que nous sommes en train de faire d'ailleurs !

Quelques questions à réponse simple pour préparer le boulot:

1. La pyramide de tuiles est de type TMS ou Google (index y inversé) ?

Google, c'est dans la norme WMTS de l'OGC (comme indiqué en réunion).

1. Cette pyramide commence au sommet par une tuile globale pour le globe, et donc les résolutions de chaque couche ne sont plus les même qu'actuellement et ne sont plus non plus des valeurs "rondes" (ex. 4,777m/px au zoom 15) ?

Oui, jettes un oeil à la documentation que nous sommes en train de faire ...

1. Si la réponse à la question 2 est oui, il n'y a donc aucune compatibilité entre les tuiles actuelles et les futures, pas seulement par déformation de projection mais aussi par changement de résolution ?

Tout à fait! Ton cache actuel n'est pas compatible avec le futur ...

1. Concernant un autre service, OpenLS: La bascule de juillet changera aussi de version de protocole ?

Oui, en 1.2 ... Là aussi, Cf. la documentation. On a encore des zones floues (une requête 1.0 sera-t-elle acceptée ?) sans réponse

1. Si oui, le nouveau sera t'il compatible ascendant sur les réponse XML ? C'est à dire que les données déjà gérées et retournées par le protocole actuel seront retournées dans les même éléments XML ?

Oui, normalement mais tu auras bien moins d'information que si tu analyses tout.

Je sais que Didier et toute l'équipe sont bien occupés mais quelques infos (!) aideraient.

Infos que l'on t'a promis pour le 12 avril (si j'ai bonne mémoire) et qui est déjà pour la très grande partie sur la documentation de travail sur http://depot.ign.fr/geoportail/api/doc/fr/

Du coup, le message est passé avant la mise en production (de mardi)

[Max_B]

Ah oui, en effet, je n'avais pas ces liens qui me donnent du grain à moudre.
Merci.

Edit: j'avais vu la norme WMTS. Je voulais lever le doute car ces normes sont difficiles à synthétiser et surtout j'avais un doute, au vu d'autres sources d'info.

[Max_B]

Je n'ai pas trouvé/compris où/comment seront spécifiées les emprises des différents territoires.

1. Cela peut être via plusieurs pyramides (TileMatrixSet), ce qui me parait adapté, mais j'avais compris qu'il y en a qu'une.
2. Il y a une section tileMatrixSetLimits prévue mais je ne la vois pas dans la copie d'écran de la doc et ne me semble pas commode pour ce point à moins de multiplier les TileMatrix
3. Ou bien spécifié "en dur", hors standard WMTS. Le GPP2 avait une définition dans le code API (Geoportal.Catalogue).

Tous les territoires sont bien prévus dans la montée des data pour juillet?

[dgrichard]

Je n'ai pas trouvé/compris où/comment seront spécifiées les emprises des différents territoires.

1. Cela peut être via plusieurs pyramides (TileMatrixSet), ce qui me parait adapté, mais j'avais compris qu'il y en a qu'une.

Une seule pyramide "mondiale"
Les territoires comme la pyramide en EPSG:3857 sont définis dans l'extension du fichier de l'autoc-configuration au niveau le plus haut.

Les territoires sont ceux déjà définis dans l'API JS (Cf. Config.js)

1. Il y a une section tileMatrixSetLimits prévue mais je ne la vois pas dans la copie d'écran de la doc et ne me semble pas commode pour ce point à moins de multiplier les TileMatrix

Tu peux aussi prendre directement la pile de résolutions donnée dans la documentation.

La formule de base est :

Code :

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

0.00028*scaleDenominator/(metre_par_inch*inch_per_unité)

1. Ou bien spécifié "en dur", hors standard WMTS. Le GPP2 avait une définition dans le code API (Geoportal.Catalogue).

L'API ne contiendra plus en dur cette spécification. C'est le service d'auto-configuration qui enverra tout cela. Mais, en attendant, tu peux "bouchonner" l'auto-configuration ...

Tous les territoires sont bien prévus dans la montée des data pour juillet?

J'y compte

[Max_B]

Les territoires comme la pyramide en EPSG:3857 sont définis dans l'extension du fichier de l'autoc-configuration au niveau le plus haut.
…
C'est le service d'auto-configuration qui enverra tout cela.

Je n'ai pas compris si ces phrases font référence à un service de configuration WMTS (GetCapabilities?) ou bien un autre de niveau supérieur (lequel)

[dgrichard]

Je n'ai pas compris si ces phrases font référence à un service de configuration WMSC (GetCapabilities?) ou bien un autre de niveau supérieur (lequel)

A un niveau supérieur aux capacités de service ...

Grosso modo, l'idée est que l'API utilise une configuration pour savoir quelles sont les ressources autorisées pour un trousseau de clefs. Cette connaissance est délivrée par un service spécial : l'auto-configuration.

Le format de l'auto-configuration est à base de WMC (Web Map Context) qui donne pour chaque ressource des informations comme quel service diffuse cette ressource, l'emprise de la ressource, son propriétaire, logo, format, légendes, etc ... Il concerne tous les services (WMTS, OpenLS, WMS, WFS, etc ...) et toutes les ressources (couches, bases de données, données dématérialisées, etc ...)

Ces informations sont aussi diffusées par les capacités de services ...

L'auto-configuration donne les informations minimales nécessaires à la création d'une application. Les détails sont trouvés via les capacités de service (par exemple: l'ensemble des systèmes de références de coordonnées supportés pour une ressource). L'avantage est ici de ne pas (comme c'est le cas actuellement) à avoir à livrer une nouvelle API si on a rajouté des nouvelles ressources sur l'infrastructure.

Tu n'as donc pas à aller chercher les capacités de service ...
Je t'ai mis en pièce attaché l'analyseur de l'auto-configuration (la partie extension, le reste tu le trouveras dans OpenLayers.Format.WMC.v1_1_0.js)

[Max_B]

OK, c'est plus clair.
Vous publierez l'URL du service d'autoconf dans la doc?

En attendant j'ai vu qu'il y a beaucoup d'informations dans le GetCapabilities du WMTS.

Pour simplifier ma transition, dans un premier temps, est-ce que je peux considérer que les bbox actuelles (GPP2) des territoires restent valides et n'avoir à ajouter que les bornes de résolutions (tileMatrix par territoire) valides dans la nouvelle pyramide ?

[dgrichard]

OK, c'est plus clair.
Vous publierez l'URL du service d'autoconf dans la doc?

Les URLs finales seront dans la documentation. Mais, les URLs d'homologation seront données à ceux qui participeront à la bascule activement

En attendant j'ai vu qu'il y a beaucoup d'informations dans le GetCapabilities du WMTS.

Il doit être nettoyé cette semaine ...

Pour simplifier ma transition, dans un premier temps, est-ce que je peux considérer que les bbox actuelles (GPP2) des territoires restent valides et n'avoir à ajouter que les bornes de résolutions (tileMatrix par territoire) valides dans la nouvelle pyramide ?

Oui

[Max_B]

Sur les pages de docs GPP3 publiées aujourd'hui, il y a l'url de l'autoconf. J'ai donc regardé immédiatement, car je cherche l'information sur quelle résolutions/tileMatrix seront disponibles par territoires.

Après un bon moment de vérification j'ai plusieurs questions:

1. La pile des résolutions publiée sur la page WMTS semble fausse. Elle ne correspond ni aux valeurs calculées depuis le rayon d'ellipsoïde, ni à la colonne des échelles à 0,00028m/px. Il doit s'agir d'une erreur dans la doc.
2. Actuellement, l'autoconf ne liste que 3 territoires: FXX, REU, GLP. On peut supposer que c'est une question de dispo ? Donc pas grave.
3. Je n'arrive pas à corréler les valeurs de ScaleDenominator. Elles ne correspondent pas à la pile standard. Du coup je ne sais pas ce qu'elles décrivent.
4. De même l'élément de territoire gpp:Resolution ne m'est pas clair. Pour REU on a une valeur de la pile mais pas pour FXX et GLP
5. Enfin, l'élément global gpp:Resolutions liste une séries de valeurs que je n'arrive pas à corréler Edit: je me suis avisé que cette liste est en degrés décimaux/pixel, "map units" openlayers

[dgrichard]

Sur les pages de docs GPP3 publiées aujourd'hui, il y a l'url de l'autoconf. J'ai donc regardé immédiatement, car je cherche l'information sur quelle résolutions/tileMatrix seront disponibles par territoires.

Publiées mardi ... (et samedi sur depot.ign.fr )
Les urls Géoportail Phase 3 (GPP3) publiées actuellement sont les futures URL de production ... Elles n'existent pour l'instant pas

Après un bon moment de vérification j'ai plusieurs questions:

1. La pile des résolutions publiée sur la page WMTS semble fausse. Elle ne correspond ni aux valeurs calculées depuis le rayon d'ellipsoïde, ni à la colonne des échelles à 0,00028m/px. Il doit s'agir d'une erreur dans la doc.

C'est moi qui les ai calculé , la formule est :

Code :

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

1
2
0.00028*scaleDenominator/(METERS_PER_INCH*INCH_PER_UNIT('m'))

Dans le cas du WMTS en Web Mercator sphérique, on devrait avoir :

Code :

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

1
2
resolution= 0.00028*scaleDenominator

après, j'ai "tronqué" le résultat à 6 chiffres ...
On a pris les formules et les avons appliquées là et jouer avec le service WMTS pour vérifier et ... c'est

1. Actuellement, l'autoconf ne liste que 3 territoires: FXX, REU, GLP. On peut supposer que c'est une question de dispo ? Donc pas grave.

Que tous les territoires ne soient pas présents, c'est normal : en chantier
Mais, d'où sorts-tu un résultat d'autoconf ? on a mis une capture d'écran en attendant de mettre un sortie plus complète ...

1. Je n'arrive pas à corréler les valeurs de ScaleDenominator. Elles ne correspondent pas à la pile standard. Du coup je ne sais pas ce qu'elles décrivent.

Comprends pô , probablement corrélé à la réponse à la question : "d'où sorts-tu l'autoconf ?"

1. De même l'élément de territoire gpp:Resolution ne m'est pas clair. Pour REU on a une valeur de la pile mais pas pour FXX et GLP

Cf. supra ...

1. Enfin, l'élément global gpp:Resolutions liste une séries de valeurs que je n'arrive pas à corréler Edit: je me suis avisé que cette liste est en degrés décimaux/pixel, "map units" openlayers

l'élements gpp:Resolutions contient les résolutions en géographiques (EPSG:4326).

De nouveau, les résolutions du Géoportail phase 3 sont les mêmes sur toutes les territoires en projection EPSG:3857.

[Max_B]

Pour le point 1 (la pile des réso dans la doc):
La formule le la résolution pour la tuile initiale EPSG:3857 donne: 2 * pi * 6 378 137 / 256 = 156 543,033928041 (≠ 156 542,636309).
Cette réso / 0,00028 = 559 082 264,028718 qui correspond à la colonne des échelles.

Pour les autres questions, liées à l'autoconf je fais un MP.

En fait pour moi, il s'agit simplement d'être sûr des résolutions, ce qui semble clair (à l'erreur de la doc près), mais surtout, savoir lesquelles seront disponibles dans la pyramide, pour chaque territoire. Je suppose que nous ne les aurons pas toutes partout.

[dgrichard]

Pour le point 1 (la pile des réso dans la doc):
La formule le la résolution pour la tuile initiale EPSG:3857 donne: 2 * pi * 6 378 137 / 256 = 156 543,033928041 (≠ 156 542,636309).
Cette réso / 0,00028 = 559 082 264,028718 qui correspond à la colonne des échelles.

Je suis parti des échelles fournies par le service WMTS ... Pas du fait que la résolution sur l'équateur par partie de 256 est bien 156543 ... la différence est de 60 cm ... T'as pris combien de décimales à pi (ok, j'exagère)

En fait pour moi, il s'agit simplement d'être sûr des résolutions, ce qui semble clair (à l'erreur de la doc près), mais surtout, savoir lesquelles seront disponibles dans la pyramide, pour chaque territoire. Je suppose que nous ne les aurons pas toutes partout.

De quelle erreur parles-tu (les 60 cm ?)

Pour chaque territoire, la résolution la meilleure ne sera pas la même effectivement ... comme c'est le cas aujourd'hui

[Max_B]

Je suis parti des échelles fournies par le service WMTS ... Pas du fait que la résolution sur l'équateur par partie de 256 est bien 156543 ... la différence est de 60 cm ... T'as pris combien de décimales à pi (ok, j'exagère)

Il s'agit donc d'une erreur d'arrondi (que je n'arrive pas a reproduire, ça doit dépendre des décimales sur la valeur initiale d'échelle).
Ça fait une différence de 40cm par pixel sur le zoom 0. Ces valeurs sont significatives si on s'en sert dans le calcul des indexes de tuiles dans la pyramide. Les documentation pour les autres pyramides EPSG:3857 (openstreetmap, etc.) partent du rayon => résolution => échelles

Il faut donc savoir quelle est la référence dans la pile GPP3.

[dgrichard]

Il s'agit donc d'une erreur d'arrondi (que je n'arrive pas a reproduire, ça doit dépendre des décimales sur la valeur initiale d'échelle).

Pas sûr que ce soit cela non plus ...

Ça fait une différence de 40cm par pixel sur le zoom 0. ces valeurs sont significatives si on s'en sert dans le calcul des indexes de tuiles dans la pyramide. Les documentation pour les autre pyramides EPSG:3857 (openstreetmap, etc.) partent du rayon => résolution => échelles

Soit, mais zoom 0, c'est le zoom Monde entier dans une image 256x256 pixels, chaque pixel fait 156km ... La procédure qui calcule le chemin /row/line/zoom prend les valeurs entières ...

Il faut donc savoir quelle est la référence dans la pile GPP3.

La table E.3 du standard OGC semble me donner raison ... et est notre référence

[Max_B]

La table E.3 du standard OGC semble me donner raison ... et est notre référence

Euh, non!
En prenant la valeur de zoom 0 : 559 082 264,028718 * 0,00028 = 156 543,033928041 C'est bien la valeur qui me semblait "juste" mais pas celle qui est listée sur la doc. Mais bon, au moins on a la référence.

[dgrichard]

Euh, non!
En prenant la valeur de zoom 0 : 559 082 264,028718 * 0,00028 = 156 543,033928041 C'est bien la valeur qui me semblait "juste" mais pas celle qui est listée sur la doc. Mais bon, au moins on a la référence.

Tu as et j'ai raison ... C'était bien un problème d'arrondi.
J'ai fait le calcul avec la formule complète en javascript et malheureusement :

Code :

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

1
2
OpenLayers.METERS_PER_INCH*OpenLayers.INCH_PER_UNIT['meter']= 1,00000254000508001 et non 1

En relançant le calcul proprement (et cette fois en C) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  0 | 156543.033928 |    559082264 |
  1 |  78271.516964 |    279541132 |
  2 |  39135.758482 |    139770566 |
  3 |  19567.879241 |     69885283 |
  4 |   9783.939621 |     34942642 |
  5 |   4891.969810 |     17471321 |
  6 |   2445.984905 |      8735660 |
  7 |   1222.992453 |      4367830 |
  8 |    611.496226 |      2183915 |
  9 |    305.748113 |      1091958 |
 10 |    152.874057 |       545979 |
 11 |     76.437028 |       272989 |
 12 |     38.218514 |       136495 |
 13 |     19.109257 |        68247 |
 14 |      9.554629 |        34124 |
 15 |      4.777314 |        17062 |
 16 |      2.388657 |         8531 |
 17 |      1.194329 |         4265 |
 18 |      0.597164 |         2133 |
 19 |      0.298582 |         1066 |
 20 |      0.149291 |          533 |
 21 |      0.074646 |          267 |

Je vais faire la màj de la documentation

[Max_B]

Pour revenir à l'autoconf, je veux bien des éclaircissements sur ceci (territoire FXX) :

Code :

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

1
2
3
<sld:MinScaleDenominator>1295.62678</sld:MinScaleDenominator>
<sld:MaxScaleDenominator>10613774.58</sld:MaxScaleDenominator>
<gpp:Resolution>1410.90756637563</gpp:Resolution>

Il y a plein de ScaleDenominator (dans le GetCapabilities aussi) avec des valeurs qui ne sont pas dans la liste de référence et dont je ne saisi pas l'unité.

[dgrichard]

Pour revenir à l'autoconf, je veux bien des éclaircissements sur ceci (territoire FXX) :

Code :

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

1
2
3
<sld:MinScaleDenominator>1295.62678</sld:MinScaleDenominator>
<sld:MaxScaleDenominator>10613774.58</sld:MaxScaleDenominator>
<gpp:Resolution>1410.90756637563</gpp:Resolution>

Il y a plein de ScaleDenominator (dans le GetCapabilities aussi) avec des valeurs qui ne sont pas dans la liste de référence et dont je ne saisi pas l'unité.

Hormis que les informations sont incorrectes, la signification des champs est :

sld:MinScaleDenominator : échelle la plus petite du territoire - DOIT être une échelle WMTS (c'est pas encore le cas)
sld:MaxScaleDenominator : échelle la plus grande du territoire - DOIT être une échelle WMTS (c'est pas encore le cas)
gpp:Resolution: résolution de visualisation si aucune n'est donnée - DOIT correspondre à une résolution du WMTS (c'est pas encore le cas).

Il y a plein d'autres informations non encore à jour dans notre configuration ...

[Max_B]

Suite à un échange en MP avec dgrichard où je me suis gravement vautré sur l'interprétation des valeurs d'échelles dans le tuilage à venir pour 2012, je pense utile de noter ce qui suit pour ceux qui utiliseront le moteur de recherche.

Dans la littérature sur les tuilages de carte en EPSG:3857 (Google, OpenstreetMap et bientôt Géoportail) on note les échelles des tuiles en mètres/pixel. De même, les coordonnées cartésiennes obtenues par les formules de transformation depuis les coordonnées géographiques sont couramment exprimées en mètres.

Il est important de saisir que ces valeurs métriques sont sur le plan de projection (cylindre développé) et non sur le géoïde ni sur l'ellipsoïde de référence.

En conséquence, toute arithmétique sur les coordonnées cartésiennes ou sur les échelles donnent des valeurs "fausses". De plus en plus fausses avec l'augmentation de la latitude.

Sous réserve de correction par les géographes/matheux, on peut retrouver des valeurs significatives en les multipliant par le cosinus de la latitude.

Exemple: soit deux coordonnées cartésiennes EPSG:3857, x1 et x2

Code :

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

1
2
x1 - x2 = d distance horizontale en m sur la projection
d * cos(latitude_radians) = D, distance sur l'ellipsoïde. (valeur approchée)

Un calcul de distance précis doit se faire par la trigo sur les coordonnées géographiques.