Alternatives à OpenLayers prenant en charge davantage de fonctionnalités côté client [fermé]

J'envisage différentes architectures pour un système qui utilisera idéalement le rendu côté client pour les fonctionnalités ponctuelles et doit être sans plugin. J'ai utilisé cette application développée en réponse à cette question pour tester mon ordinateur portable (qui est tout à fait capable - processeur quad-core 2,6 GHz, 4 Go de mémoire, sous aucune autre charge, Firefox 8) avec différents nombres de points dans OpenLayers et il est sensiblement à la traîne à 500 et commence à en avoir plus de 1000. Les fonctionnalités générées de manière aléatoire ne semblent pas avoir de gestionnaires d'événements et utilisent toutes la même symbologie.

Je m'attends à afficher jusqu'à 1 000 fonctionnalités, avec jusqu'à 10 symboles différents, toutes avec des gestionnaires de clic et de souris, et sur des plateformes moins performantes.

J'espérais de meilleures performances côté client, surtout après avoir vu cet exemple GIS Cloud - je sais que cela fonctionne différemment (HTML5 canvas vs SVG) mais la différence de performances est vraiment frappante.

Mes questions clés (si vous voulez bien) sont:

1. L'application de génération de points aléatoires est-elle représentative des performances des autres applications OpenLayers que vous avez écrites / utilisées?
2. Existe-t-il une API de cartographie Web alternative éprouvée et gratuite qui prend en charge les services WMS (que je dois utiliser) et est plus rapide avec les fonctionnalités côté client, sans utiliser Flash / Silverlight / aucun autre plug-in?
3. Avez-vous d'autres suggestions sur ce que je devrais étudier?

S'appuyer principalement sur le rendu côté serveur est une option, mais le client et moi-même aimerions éviter cela en raison de préoccupations concernant l'augmentation du nombre d'utilisateurs et la réactivité de l'interface utilisateur.

La réponse à la 1ère question est oui . Vous utilisez OL avec une configuration assez courante. Il existe des astuces que vous pouvez utiliser pour améliorer les performances, j'y reviendrai plus tard.

La réponse à la question 2 est peut-être (en particulier en ce qui concerne la solidité). Vous pouvez rechercher sur ce site une liste d'alternatives (celle qui vient à l'esprit en ce moment est Leaflet ).

Réponse à la question 3: commencez par mesurer:

J'ai modifié une copie locale de l' application afin que le rendu soit explicitement spécifié dans la liste d'options pour la couche Vector. Pendant les tests, j'omettais le moteur de rendu Canvas, puis je rechargeais la page avec un autre:

var pts = new OpenLayers.Layer.Vector("Points", {renderers: ["Canvas", "SVG", "VML"]});

J'ai ajouté une minuterie à la fonction de rafraîchissement pour qu'elle affiche le temps passé à dessiner :

function redraw() {
var start = (new Date).getTime();
[...]
var diff = (new Date).getTime() - start;
console.log("redraw completed in "+diff+"ms");

Après cela, j'ai essayé plusieurs exécutions sur Chrome 17 et Firefox 8.0.1 sur OSX SL dessinant les fonctionnalités 1000 et 5000. À ma grande surprise, le rendu SVG est en moyenne 20% plus rapide que le rendu Canvas! (Remarque: sous Windows js, le temps n'est pas aussi précis que sous OSX, les résultats pourraient donc être moins cohérents).

Ceci et vous dites que

c'est l'interaction de la carte qui est le problème

, À mon humble avis, nous dit que le hotspot est dans la gestion vectorielle des fonctionnalités. Tout en travaillant sur une de mes applications, je l'ai récemment regardée et j'ai décidé de la sous-classer, puis de la débarrasser de tout le code compliqué qui ne sert à rien pour les points simples. Certes, je suis devenu assez sauvage et j'ai même supprimé la dépendance à OpenLayers.Geometry.Point et ma version fonctionne maintenant sur des objets js simples avec des attributs x, y.

Vos options sont, par ordre décroissant avantages / coûts:

La première option consiste à filtrer les points visibles côté serveur en configurant une option de stratégie sur la couche vectorielle comme suit:

 strategies: [new OpenLayers.Strategy.Refresh({force:true}), new OpenLayers.Strategy.BBOX({ratio:2, resFactor: 3})],

De cette façon, lorsque vous effectuez un zoom avant, le nombre de fonctionnalités côté client dessinées sera limité à celles qui sont visibles dans cette mesure, au lieu de toutes.

Comme deuxième option, vous pourriez envisager d' écrire un vecteur / rendu personnalisé . Un exemple d'implémentation personnalisée, simplifiée et plus rapide est disponible sur ma page github ici . Bien qu'il ne convienne pas à toutes les utilisations, il devrait suffire de donner une idée approximative de ce que je propose.

La troisième option lorsque l'utilisateur est complètement dézoomé consiste à implémenter une sorte de regroupement des fonctionnalités côté serveur afin que les points de fermeture soient fusionnés en un seul, réduisant encore le nombre de fonctionnalités dessinées.

En utilisant UTFGrid et TileMill, vous pouvez afficher un nombre illimité de points avec de très bonnes performances. L'affichage de n points aléatoires est une sorte d'exemple artificiel qui ne fonctionnerait pas dans cette situation ou avec GISCloud ou toute magie similaire, car les hacks de performance vectorielle nécessitent généralement la connaissance de l'ensemble de données complet et un certain prétraitement: TileMill et GISCloud le font beaucoup de carrelage.