Alternativas de OpenLayers que admiten más funciones del lado del cliente [cerrado]

Estoy considerando diferentes arquitecturas para un sistema que idealmente utilizará la representación del lado del cliente para las características de punto y debe estar libre de complementos. He estado utilizando esta aplicación desarrollada en respuesta a esta pregunta para probar mi computadora portátil (que es bastante capaz: CPU de cuatro núcleos de 2.6 ghz, memoria de 4 gb, no bajo ninguna otra carga, Firefox 8) con diferentes números de puntos en OpenLayers y está notablemente rezagado en 500 y comienza a superar los 1,000. Las características generadas al azar no parecen tener ningún controlador de eventos y todas usan la misma simbología.

Espero mostrar hasta 1,000 funciones, con hasta 10 símbolos diferentes, todos con controladores de clic y mouse-over, y en plataformas menos capaces.

Esperaba un mejor rendimiento del lado del cliente, especialmente después de ver este ejemplo de GIS Cloud : sé que funciona de manera diferente (lienzo HTML5 vs. SVG), pero la diferencia en el rendimiento es realmente sorprendente.

Mis preguntas clave (si fuera tan amable) son:

1. ¿La aplicación generadora de puntos aleatorios es representativa del rendimiento en otras aplicaciones OpenLayers que ha escrito / utilizado?
2. ¿Existe una API de mapeo web alternativa probada y gratuita que sea compatible con los servicios WMS (que necesito usar) y sea más rápida con las funciones del lado del cliente, sin usar Flash / Silverlight / ningún otro complemento?
3. ¿Alguna otra sugerencia sobre lo que debería estar investigando?

Confiar principalmente en la representación del lado del servidor es una opción, pero tanto a mí como al cliente nos gustaría evitar esto debido a las preocupaciones sobre la ampliación de los números de usuario y la capacidad de respuesta de la interfaz de usuario.

La respuesta a la primera pregunta es sí . Estás utilizando OL con una configuración bastante común. Hay trucos que puedes usar para mejorar el rendimiento, lo abordaré más adelante.

La respuesta a la pregunta 2 es quizás (especialmente con respecto a la solidez). Puede buscar en este sitio una lista de alternativas (una que me viene a la mente en este momento es Leaflet ).

Respuesta a la pregunta 3: comience con la medición:

Edité una copia local de la aplicación para que el procesador se especifique explícitamente en la lista de opciones para la capa Vector. Durante las pruebas, omitiría el renderizador de Canvas y luego volvería a cargar la página del experimento con una diferente:

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

Agregué un temporizador a la función de volver a dibujar para que imprima cuánto tiempo pasó dibujando :

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

Después de eso, probé varias ejecuciones en Chrome 17 y Firefox 8.0.1 en OSX SL con las características 1000 y 5000. Para mi sorpresa, el renderizador SVG es en promedio un 20% más rápido que el renderizador Canvas. (Nota: en Windows js el tiempo no es tan preciso como en OSX, por lo que los resultados podrían ser menos consistentes).

Esto y tu diciendo que

es la interacción del mapa ese es el problema

, En mi humilde opinión, nos dice que el punto de acceso está en el manejo del vector de características. Mientras trabajaba en una aplicación mía, recientemente la miré y decidí subclasificarla y luego eliminar todo el código complicado que no sirve para puntos simples. Es cierto que me volví bastante loco e incluso eliminé la dependencia de OpenLayers.Geometry.Point y mi versión ahora funciona en objetos js simples con atributos x, y.

Sus opciones son, por orden de beneficio / costo:

La primera opción es filtrar los puntos visibles del lado del servidor configurando una opción de estrategia para la capa vectorial como la siguiente:

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

De esta forma, cuando amplíe la cantidad de características dibujadas del lado del cliente, se limitará a aquellas que sean visibles en ese punto, en lugar de todas.

Como segunda opción, puede considerar escribir un Vector / Render personalizado . Un ejemplo de una implementación personalizada, simplificada y más rápida está disponible en mi página de github aquí . Si bien no es adecuado para todos los usos, debería ser suficiente para dar una idea aproximada de lo que estoy sugiriendo.

La tercera opción para cuando el usuario está completamente alejado es implementar algún tipo de agrupación de características del lado del servidor para que los puntos cercanos se fusionen en uno solo, reduciendo nuevamente el número de características dibujadas.

Usando UTFGrid y TileMill puede mostrar puntos ilimitados con un rendimiento bastante bueno. Sin embargo, mostrar n puntos aleatorios es una especie de ejemplo artificial que no funcionaría en esa situación o con GISCloud o cualquier magia similar, ya que los hacks de rendimiento de vectores generalmente requieren el conocimiento del conjunto de datos completo y algo de procesamiento previo: tanto TileMill como GISCloud hacen muchos azulejos