Alternativas ao OpenLayers que suportam mais recursos do lado do cliente [fechado]

Estou pensando em arquiteturas diferentes para um sistema que idealmente usará a renderização do lado do cliente para recursos de ponto e deve ser livre de plug-ins. Eu tenho usado este aplicativo desenvolvido em resposta a esta pergunta para testar meu laptop (que é bastante capaz - cpu quad-core de 2.6 ghz, memória de 4 gb, sem nenhuma outra carga, Firefox 8) com diferentes números de pontos nos OpenLayers e está visivelmente atrasado em 500 e começa a lutar por mais de 1.000. Os recursos gerados aleatoriamente não parecem ter nenhum manipulador de eventos e todos usam a mesma simbologia.

Espero exibir até 1.000 recursos, com até 10 símbolos diferentes, todos com manipuladores de clique e mouse e em plataformas menos capazes.

Eu esperava um melhor desempenho do cliente, especialmente depois de ver este exemplo da GIS Cloud - eu sei que funciona de maneira diferente (tela HTML5 vs. SVG), mas a diferença de desempenho é realmente impressionante.

Minhas principais perguntas (se você for tão gentil) são:

1. O aplicativo de geração de pontos aleatórios representa o desempenho em outros aplicativos OpenLayers que você escreveu / usou?
2. Existe uma API de mapeamento da web alternativa gratuita e comprovada que ofereça suporte aos serviços WMS (que eu preciso usar) e seja mais rápida com os recursos do cliente, sem usar o Flash / Silverlight / outros plugins?
3. Alguma outra sugestão sobre o que eu deveria estar investigando?

Confiar principalmente na renderização do lado do servidor é uma opção, mas eu e o cliente gostariamos de evitar isso devido a preocupações com o aumento do número de usuários e a capacidade de resposta da interface do usuário.

A resposta à 1ª pergunta é Sim . Você está usando OL com uma configuração bastante comum. Existem truques que você pode usar para melhorar o desempenho, abordarei isso mais tarde.

A resposta à pergunta 2 é talvez (especialmente com relação à rapidez). Você pode procurar neste site uma lista de alternativas (uma que vem à mente agora é o Leaflet ).

Resposta à pergunta 3: comece medindo:

Editei uma cópia local do aplicativo para que o representante seja especificado explicitamente na lista de opções da camada Vetor. Durante os testes, eu omitia o renderizador do Canvas e recarregava a página do experimento com outro diferente:

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

Eu adicionei um timer à função redesenhar para que ele imprima quanto tempo gastou desenhando :

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

Depois disso, tentei várias execuções no Chrome 17 e Firefox 8.0.1 no OSX SL, desenhando os recursos 1000 e 5000. Para minha surpresa, o renderizador SVG é em média 20% mais rápido que o renderizador Canvas! (Nota: no Windows js o tempo não é tão preciso quanto no OSX, portanto, os resultados podem ser menos consistentes).

Isso e você está dizendo isso

é a interação do mapa que é o problema

, IMHO, nos diz que o ponto de acesso está no manuseio de recursos de vetores. Enquanto trabalhava em um aplicativo meu, recentemente dei uma olhada nele e decidi subclassificá-lo e depois livrar-me de todo o código complicado que não serve para nada. É verdade que fiquei bastante louco e até removi a dependência do OpenLayers.Geometry.Point e minha versão agora funciona em objetos js simples com atributos x, y.

Suas opções são, em ordem decrescente de benefício / custo:

A primeira opção é filtrar os pontos visíveis do lado do servidor, configurando uma opção de estratégia para a camada vetorial, como a seguir:

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

Dessa forma, quando você aumentar o zoom no número de recursos desenhados no lado do cliente, ficará limitado àqueles visíveis nessa extensão, em vez de todos.

Como segunda opção, você pode considerar escrever um Vector / Renderer personalizado . Um exemplo de uma implementação personalizada, simplificada e rápida está disponível na minha página do github aqui . Embora não seja adequado para todos os usos, deve ser suficiente para dar uma idéia aproximada do que estou sugerindo.

A terceira opção para quando o usuário está totalmente reduzido é implementar algum tipo de cluster de recursos no servidor, para que os pontos de fechamento sejam mesclados em um único, reduzindo novamente o número de recursos utilizados.

Usando UTFGrid e TileMill, você pode exibir pontos ilimitados com desempenho muito bom. A exibição de n pontos aleatórios é uma espécie de exemplo artificial que não funcionaria nessa situação ou com o GISCloud ou qualquer mágica similar - já que os hacks de desempenho de vetor geralmente exigem conhecimento do conjunto de dados completo e algum pré-processamento: o TileMill e o GISCloud um monte de azulejos.