Discussion :

[cmail]

Dans cette page on peut lire:

Il a été mesuré qu'au delà de 200 objets des ralentissements sont perceptibles.

Ma question est de savoir ce que vous entendez par "objets".
Ainsi, dans un <Polygon> d'un fichier kml est-ce que chaque point de coordonnées est considéré comme un objet?
Mon idée est d'augmenter le nombre de ces points pour avoir un polygone moins grossier, plus arrondi suivant davantage les repères de cartes à petite échelle. Mais sera-ce au détriment de la rapidité (bien sûr un peu, puisque les données texte du kml seront plus importantes...)

[mga_geo]

J'ai des fichiers avec plusieurs centaines de "Placemark" et de "Polygon" (carré):
de l'ordre de 400 pour chaque.
Effectivement l'affichage en prend un coup. Lorsque que je passe au niveau centaine, je n'ai plus de problèmes.

NB: Ces fichiers correspondent à la découpe en carré de 10x10km de la région Bretagne ou d'un département

[dgrichard]

L'objet correspond à OpenLayers.Feature. Le nombre avancé (200) dépend de beaucoup de facteurs :

1. 200 points chacun avec un picto différent et un popup HTML sont plus lents à afficher que 200 points sans popup;
2. 200 lignes de 2 points s'affichent plus vite que 200 lignes de 100 points;
3. 200 polygones simples (5 points) pas coloriés s'affichent plus vite que 200 polygones simples coloriés en fonction d'une propriété qu'il porte.

Les fichiers type KML/GPX sont chargés par OpenLayers en créant des objets OpenLayers.Feature qui portent la géométrie et les propriétés dans la mémoire du navigateur. On imagine que les combinaisons géométrie + propriété + rendu final à l'écran sont des facteurs de ralentissements.

L'autre facteur est que le chargement de tels objets est fait en une fois : même si les objets ne sont pas affichés dans la fenêtre active. C'est une soluce idéal pour des phénomènes ponctuelles, très lourde pour une données de grande étendue. Dans ce dernier cas, il vaut mieux utiliser d'autres flux comme les WFS ...