Discussion :

[cmail]

Suite à cette discussion,
j'essaye de modifier autoconf.xml.

Ma première page d'essai n'est pas une réussite

1/ Firebug m'indique une erreur de syntaxe. Mouais? Mais encore?
2/ Dans ce nouveau autoconfig j'ai enlevé tous les appels à des territory autre que FXX (pour voir si cela accélère le chargement), j'ai remplacé le point de référence sur Paris et j'ai changé la BoudingBox pour ne plus avoir de vilains effets visuels de préchargement sur la carte de France centrée sur Paris.
3/ Avant de m'attaquer à d'autres paramètres...

Que pensez-vous de cette démarche?

[mga_geo]

J'ai aussi fait un essai : http://mga.alwaysdata.net/geoportail...conf.html?json (sans le json de la fin, charge l'autoconf à partir du site api).
Effectivement, cela améliore le temps de réponse :

site api
Page title is autoconf
Loading time 17353 msec
site web
Page title is autoconf
Loading time 11364 msec
site api
Page title is autoconf
Loading time 16554 msec
site web
Page title is autoconf
Loading time 10896 msec
site api
Page title is autoconf
Loading time 13909 msec
site web
Page title is autoconf
Loading time 9697 msec
site api
Page title is autoconf
Loading time 12498 msec
site web
Page title is autoconf
Loading time 10966 msec
site api
Page title is autoconf
Loading time 17615 msec
site web
Page title is autoconf
Loading time 10856 msec
site api
Page title is autoconf
Loading time 15768 msec
site web
Page title is autoconf
Loading time 9070 msec
site api
Page title is autoconf
Loading time 14243 msec
site web
Page title is autoconf
Loading time 12491 msec
site api
Page title is autoconf
Loading time 15770 msec
site web
Page title is autoconf
Loading time 11253 msec
site api
Page title is autoconf
Loading time 16027 msec
site web
Page title is autoconf
Loading time 11229 msec
site api
Page title is autoconf
Loading time 14308 msec
site web
Page title is autoconf
Loading time 8870 msec

Sur ces essais, je ne m'explique pas la fluctuation du temps de réponse.

[gcebelieu]

Suite à cette discussion,
j'essaye de modifier autoconf.xml.

Ma première page d'essai n'est pas une réussite

1/ Firebug m'indique une erreur de syntaxe. Mouais? Mais encore?

l'erreur vient du fait que le fichier d'autoconf est en xml. Il faut utiliser la réponse au format JSONP ; à savoir, celle retournée par la requête :

http://wxs.ign.fr/[clé]/autoconf/?output=json&callback=OpenLayers.Protocol.Script.registry.regId1

2/ Dans ce nouveau autoconfig j'ai enlevé tous les appels à des territory autre que FXX (pour voir si cela accélère le chargement), j'ai remplacé le point de référence sur Paris et j'ai changé la BoudingBox pour ne plus avoir de vilains effets visuels de préchargement sur la carte de France centrée sur Paris.
3/ Avant de m'attaquer à d'autres paramètres...

Que pensez-vous de cette démarche?

Sur le fait d'alléger le fichier d'autoconf en fonction de l'utilisation qu'on va en faire, la démarche est bonne pour accélérer le chargement.

Sinon, sur le fait de modifier des valeurs d'initialisation : que ce soit dans le fichier d'autoconf ou dans le javascript, je ne pense pas qu'une méthode soit meilleure que l'autre...

[mga_geo]

Le même test donne de meilleurs temps de réponse ce matin, il y a donc quelque part un ou plusieurs éléments du réseau qui sature !

site api
Page title is autoconf
Loading time 4875 msec
site web
Page title is autoconf
Loading time 4192 msec
site api
Page title is autoconf
Loading time 4359 msec
site web
Page title is autoconf
Loading time 5184 msec
site api
Page title is autoconf
Loading time 4339 msec
site web
Page title is autoconf
Loading time 4218 msec
site api
Page title is autoconf
Loading time 4508 msec
site web
Page title is autoconf
Loading time 4091 msec
site api
Page title is autoconf
Loading time 4466 msec
site web
Page title is autoconf
Loading time 4269 msec
site api
Page title is autoconf
Loading time 4441 msec
site web
Page title is autoconf
Loading time 4186 msec
site api
Page title is autoconf
Loading time 4437 msec
site web
Page title is autoconf
Loading time 4351 msec
site api
Page title is autoconf
Loading time 4398 msec
site web
Page title is autoconf
Loading time 4190 msec
site api
Page title is autoconf
Loading time 4553 msec
site web
Page title is autoconf
Loading time 4198 msec
site api
Page title is autoconf
Loading time 4351 msec
site web
Page title is autoconf
Loading time 4279 msec

[cmail]

Sur le fait d'alléger le fichier d'autoconf en fonction de l'utilisation qu'on va en faire, la démarche est bonne pour accélérer le chargement.

Bon, je vais refaire mes essais de simplification aujourd'hui...
Sur les <territory> pas de problème>> je comprends bien ce qui est superflu.
Après, on passe au <tilematrix>: là c'est un peu plus hermétique pour modifier ce qui est non adapté!
Mais après ces <tilematrix>: là, ce sera très compliqué sans une documentation précise...
Avez-vous cela?

Sinon, sur le fait de modifier des valeurs d'initialisation

Cette modification n'a pas pour but d'améliorer les vitesses de chargement, mais d'éviter des effets visuels très déplaisants (comme le pré-chargement de tuile de la France entière ou de Paris, avant d'avoir les tuiles demandées au bon zoom et centrées sur son "center") .
Est-ce que mon raisonnement est cohérent?

[cmail]

Bon, j'ai trituré mon autoconfig en conséquence de vos réponses. Merci.

J'obtiens une bonne réponse....

Je constate une nette amélioration dans la vitesse de réponse.

Mais comment on fait quand on charge plusieurs viewers sur la même page???

Genre : Geoportal.GeoRMHandler.getConfig(['XXX','YYY', 'ZZZ'], null, Quel autoconfig ?, {....

[gcebelieu]

Bon, je vais refaire mes essais de simplification aujourd'hui...
Sur les <territory> pas de problème>> je comprends bien ce qui est superflu.
Après, on passe au <tilematrix>: là c'est un peu plus hermétique pour modifier!
Mais après ces <tilematrix>: là, ce sera très compliqué sans une documentation précise...
Avez-vous cela?

Pour les <tilematrix>, le fichier d'autoconf reprend les informations retournées par le GetCapabilities du serveur WMTS. En gros, il s'agit de la description des dallages utilisés pour les pyramides de tuiles du WMTS.

En termes de doc, on peut donc trouver :

1. le standard WMTS
2. une page expliquant le WMTS sur le site api.ign.fr

3. un tutoriel décrivant sommairement le contenu de l'autoconf.

Sinon, au niveau de l'autoconf, il parait délicat de faire des coupes dans cette partie car les informations véhiculées sont nécessaires pour l'affichage des couches Géoportail (à moins de ne pas utiliser les couches WMTS).
Le <TileMatrixSet> dont l'identifiant est "PM" décrit la pyramide pour les tuiles calculées dans le système de référence "PseudoMercator" (epsg:3857). C'est celui qui est utilisé pour les APIs 2D. Si d'autre balises <TileMatrixSet> apparaissent (ce qui n'est normalement pas le cas pour les clefs délivrées), on peut éventuellement s'en passer.

Cette modification n'a pas pour but d'améliorer les vitesses de chargement, mais d'éviter des effets visuels très déplaisants (comme le pré-chargement de tuile de la France entière ou de Paris, avant d'avoir les tuiles demandées au bon zoom et centrées sur son "center") .
Est-ce que mon raisonnement est cohérent?

Oui, il faut tester.

[cmail]

Mais encore...
Dans la page sur l'auto-configuration je lis:

Taille de la visualisation.

• Territoire par défaut avec ses paramètres: centre, résolution, emprise et projection.

• Couches par défaut avec leurs paramètres: nom, protocole, url, projection,
emprises, logos, légendes, thèmes...

• Liste des territoires avec leurs paramètres (alimente la combo box du
TerritoryNavigator).

• Liste des TileMatrixSet avec leurs paramètres.

• Liste des résolutions correspondant aux niveaux de zoom discrets.

• Liste des services Géoportail avec leur url d'accès.

• Liste des couches avec leurs paramètres (alimente le catalogue de couches).

A votre avis, dans un premier temps, quels sont les chapitres qui sont modifiables sans grande conséquence sur la gestion générale de l'API?

[gcebelieu]

Mais comment on fait quand on charge plusieurs viewers sur la même page???

Genre : Geoportal.GeoRMHandler.getConfig(['XXX','YYY', 'ZZZ'], null, Quel autoconfig ?, {....

L'appel de l'autoconf avec plusieurs clefs :

Code :

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

1
2
Geoportal.GeoRMHandler.getConfig(['XXX','YYY', 'ZZZ'], null, ...

se traduit par un seul appel au service d'autoconf avec plusieurs clefs. normalement quelque chose comme ça :

http://wxs.ign.fr/XXX/autoconf/?apik...egistry.regId1

Au niveau du résultat, la partie <General> (celle qui contient les infos d'initialisation sur les territoires, les tilematrixset et les services) reste la même. C'est la partie <LayerList> (celle qui contient la liste des couches auxquelles les clefs donnent droit) qui va être modifiée (selon les droits donnés par les différentes clefs).

Du coup on peut difficilement initialiser différemment plusieurs viewers par cette manière.

Si on veut faire cela, il vaut mieux passer par le loader en faisant plusieurs appels à Geoportal.load en utilisant des fichiers d'autoconf différents pour chacun d'eux :

Code :

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

1
2
3
4
5
6
7
8
iv1= Geoportal.load(
            viewerDiv1, [key1], ... , ... , { geormUrl: 'chemin/vers/autoconf1.json'} 
       );
iv2= Geoportal.load(
            viewerDiv2, [key2], ... , ... , { geormUrl: 'chemin/vers/autoconf2.json'} 
       );
...

(remarque : key1 et key2 peuvent être les mêmes)
Dans ce cas, on peut peaufiner différemment les paramètres d'initialisation pour chacun des viewers.

[gcebelieu]

A votre avis, dans un premier temps, quels sont les chapitres qui sont modifiables sans grande conséquence sur la gestion générale de l'API?

A mon avis :

Taille de la visualisation.

on doit pouvoir s'en passer (même si ça pèse rien dans le fichier d'autoconf).

• Territoire par défaut avec ses paramètres: centre, résolution, emprise et projection.

il s'agit juste d'un attribut indiquant que l'un des territoires décrit est celui par défaut.
On peut ne pas le mentionner, si on spécifie le territoire dans l'initialisation du viewer, mais je ne voie pas l'intérêt.

• Couches par défaut avec leurs paramètres: nom, protocole, url, projection,
emprises, logos, légendes, thèmes...

Il s'agit des couches par défaut à afficher pour un territoire donné.
On doit pouvoir s'en passer, si, pour le territoire en question, on souhaite afficher spécifiquement une couche que l'on mentionne dans l'initialisation du viewer.

• Liste des territoires avec leurs paramètres (alimente la combo box du
TerritoryNavigator).

On peut s'en passer si on souhaite limiter l'application à la visualisation sur un seul territoire ou à une liste spécifique de territoires. Dans ce cas, on ne laisse que la définition des territoires souhaités.

• Liste des TileMatrixSet avec leurs paramètres.

comme dit précédemment : on ne peut s'en passer que si on n'utilise pas le service WMTS.

• Liste des résolutions correspondant aux niveaux de zoom discrets.

on en a besoin.

• Liste des services Géoportail avec leur url d'accès.

On peut enlever les services dont on ne se sert pas.

• Liste des couches avec leurs paramètres (alimente le catalogue de couches).

On peut supprimer la description des couches dont on ne va pas se servir (cette limitation peut aussi se faire lors du choix des couches à la création de la clef).

[mga_geo]

En ne gardant que la métropole, au niveau des territoires, on passe de 337988 à 317476 sur le fichier de configuration.
On gagne donc 20 ko sur les 1,3 Mo du chargement initial.

[gcebelieu]

En effet, là où on va arriver à gagner en taille, c'est en jouant :
-> sur les territoires
-> sur les couches (si on en utilise peu)
-> sur les tilematrixset (si on n'utilise pas le WMTS)

[cmail]

Je ne comprends vraiment pas très bien tous ces rouages:

En ne gardant que la métropole, au niveau des territoires, on passe de 337988 à 317476 sur le fichier de configuration.

Avec ma configuration, je suis passé de 54,4ko (fichier autoconfig d'origine) à 27,7 ko après avoir supprimé tous les territoires sauf FXX. Je trouve que la taille du fichier de Marc est très très gros?

On gagne donc 20 ko sur les 1,3 Mo du chargement initial.

Ce qui est très peu! Et donc ne vaut pas trop la peine de s'emmerder avec ces modifs. Non? Malgré ce que dit gcebelieu.

Pour ma part: Cette page est avec le autoconfig automatique de l'IGN et cette page est avec un autoconfig perso où j'ai supprimé tous les territoires autres que FXX et 3 couches sur les 5 de l'abonnement d'origine.
Finalement en regardant les temps de chargement (ou les octets) dans firebug de ces deux solutions, je ne trouve pas de grandes modifications. En gros chargement total de 1,2 Mo pour environ 5 s. (ici, avec ma connexion) suivants les moments d'essai.

Qu'en pensez-vous?

[gcebelieu]

Si on résume, l'intérêt que l'on peut trouver à charger l'autoconf en local c'est :

-> passer d'une génération dynamique du fichier d'autoconf à un fichier statique (il n'y a pas que la taille du fichier qui peut ralentir le chargement). Même s'il existe une gestion de caches côté serveurs IGN, ceux-ci sont régulièrement mis à jour et la génération peut prendre un peu de temps.
-> modifier les paramètres d'initialisation par défaut
-> tailler les données données d'initialisation plus finement par rapport à l'utilisation que l'on veut faire (et donc optimiser quand même la taille des données).
-> on doit pouvoir aussi (non testé) s'amuser à rajouter des couches qui ne sont pas servies par le Géoportail mais dont la manipulation par l'API sera ainsi facilitée car elles seront vues comme des couches Géoportail.

Après, c'est selon les cas d'utilisation que l'on peut juger de l’opportunité de le faire ou pas.

[cmail]

Même si je ne comprends pas tout, je constate un intérêt à travailler sur ce fichier pour le chargement des données IGN...

Pour aller plus loin dans la rapidité de chargement de l'api JS, je me pose la question suivante:
Ne serait-il pas possible (pas forcément dans autoconf.xml) de charger en priorité GeoportalMin.js (<200 ko en gzip) puis une fois que l'affichage du viewer est ok (l'api chargé avec ses tuiles autoconfigurées) de compléter le chargement par une bibliothèque complémentaire JS (fournie par IGN) pour obtenir par exemple les potentialités de GeoportalExtended.js (>650 ko en gzip)?

L'idée serait d'étager le chargement de GeoportalExtended.js pour que les utilisateurs-visiteurs non pro (avec des vitesses adsl de "province") ne soient pas perturbés par les lenteurs de chargement de l'api. Bien sur, il y a un gif animé en guise de patience, mais quand même....
Faites-vous des essais avec des vitesses de chargement de l'ordre de 2 à 4 Mb/s comme on a en milieu rural (80% du territoire, 20% de la population)?

[gcebelieu]

Pour aller plus loin dans la rapidité de chargement de l'api JS, je me pose la question suivante:
Ne serait-il pas possible (pas forcément dans autoconf.xml) de charger en priorité GeoportalMin.js (<200 ko en gzip) puis une fois que l'affichage du viewer est ok (l'api chargé avec ses tuiles autoconfigurées) de compléter le chargement par une bibliothèque complémentaire JS (fournie par IGN) pour obtenir par exemple les potentialités de GeoportalExtended.js (>650 ko en gzip)?

En effet, on pourrait imaginer de proposer un chargement des fonctionnalités de l'API dans un mode "légos" (chargement d'une bibliothèque minimale puis chargement de différents "packages" selon les fonctionnalités voulues par le développeur) plutôt que dans le mode monolithique proposé actuellement. Il faudrait pour cela étudier les découpages possibles de l'API et d'OpenLayers, puis revoir les procédures d'assemblage et de distribution de l'API. Cela étant dit, ce n'est pas d'actualité pour l'instant et je ne suis pas certain d'un gain énorme en rapidité... à voir.

Au passage, l'API minimum ne contient pas le viewer. Il faudrait donc charger un peu plus de fonctionnalités pour afficher celui-ci dans un premier temps.

L'idée serait d'étager le chargement de GeoportalExtended.js pour que les utilisateurs-visiteurs non pro (avec des vitesses adsl de "province") ne soient pas perturbés par les lenteurs de chargement de l'api. Bien sur, il y a un gif animé en guise de patience, mais quand même....
Faites-vous des essais avec des vitesses de chargement de l'ordre de 2 à 4 Mb/s comme on a en milieu rural (80% du territoire, 20% de la population)?

Il ne faut pas souffrir du complexe du provincial vis à vis du parisien .
Nous n'avons pas besoin de mettre en place de tests spécifiques pour expérimenter des vitesses de chargement modérées, voire lentes même en étant à 5 mn en métro de la capitale.

[cmail]

Et comment appelle-t-on l'autoconfig quand on utilise le loader?
Un exemple?

[gcebelieu]

L'autoconf est appelée automatiquement par le loader (pas d'appel explicite). On peut modifier l'adresse du fichier d'autoconf à l'aide du paramètre "geormUrl' que l'on indique dans les options du 5ième paramètre du loader :

Code :

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

1
2
3
4
iv= Geoportal.load(
            viewerDiv, [key], ... , ... , { geormUrl: 'chemin/vers/autoconf.json'} 
       );

[cmail]

Peut-on (et donc comment?) faire pour changer (astucieusement) certains paramètres du fichier autoconfig.json?

Explications:
J'ai une première carte départementale (dans un viewer0) ou le visiteur clique sur une commune pour ouvrir un deuxième écran avec un autre viewer (viewer1). J'aimerais que l'autoconfig du viewer1 intègre "automatiquement" les lat et lon de la commune choisie pour éviter d'avoir toujours un pré-affichage (parfois rapide, parfois non, mais toujours visible et donc désagréable) sur les coordonnées de base de l'autoconfig.
Même si après trituration de l'autoconfig, je ne suis plus pré-centré sur Paris, cela n'est pas très propre d'avoir une apparition d'une commune de référence autre que celle demandée...

Je regarde bien du coté de Geoportal.GeoRMHandler, mais je m'y perds!

[betechsud]

moi j'évite ce pré-affichage en récupérant la lat/long ou la commune en php qui initialise des variables javascripts (dans le code ville, territoire, initLng et initLat).
Ensuite je charge l'api de la façon suivante :

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
24
25
26
27
28
   if (initLng == null)
   {
      var Position = {place: ville};
   }
   else
   {
      var Position = {lon: initLng, lat: initLat};
   }
   iVIEWER = new Geoportal.load(
      "map",
      // la ou les clefs :
      ['Clef'],
      Position,
      initZoom,
      {
         language: 'fr',
         // permet d'éviter le marker par défaut
         overlays: {},
         mode: 'normal',
         territory: territoire,
         // UTILISATION du visualiseur par défaut :
         viewerClass: Geoportal.Viewer.Default,
         // APPEL à initGeoportalMap pour terminer le travail :
         onView: initGeoportalMap
      }
   );
}