Alternativas de OpenLayers que admiten más características del lado del cliente [cerrado]

14

Estoy considerando diferentes arquitecturas para un sistema que idealmente usará la representación del lado del cliente para las características de puntos 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 - quad-core 2.6 ghz cpu, 4 gb de memoria , no bajo ninguna otra carga, Firefox 8) con diferentes números de puntos en OpenLayers y se está retrasando notablemente en 500 y comienza a luchar por más de 1,000. Las características generadas aleatoriamente 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 con menos capacidad.

Esperaba un mejor desempeño del lado del cliente, especialmente después de ver este ejemplo de la Nube GIS - 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 de generación de puntos aleatorios es representativa del rendimiento en otras aplicaciones de OpenLayers que ha escrito / usado?
  2. ¿Existe una API de mapas web alternativa probada y gratuita que admita los servicios WMS (que debo usar) y es más rápida con las características 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 yo como el cliente nos gustaría evitar esto debido a las preocupaciones sobre la ampliación de los números de usuarios y la capacidad de respuesta de la interfaz de usuario.

    
pregunta tomfumb 07.01.2012 - 20:49

2 respuestas

23

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

La respuesta a la pregunta 2 es quizás (especialmente en lo que respecta a la rapidez). Puede buscar en este sitio una lista de alternativas (una que me viene a la mente ahora es Leaflet ).

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

Edité una copia local de la aplicación para que el renderizador 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 otra diferente:

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

Agregué un temporizador a la función de redibujo 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 tanto en Chrome 17 como en Firefox 8.0.1 en OSX SL, con características de 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 lo dices

  

el problema es la interacción del mapa

, IMHO, nos dice que el punto de acceso está en el manejo de características de Vector. Mientras trabajaba en una aplicación mía, recientemente la examiné y decidí crear una subclase y luego eliminarla de todos los códigos complicados que no sirven para puntos simples. Es cierto que me volví bastante salvaje e incluso eliminé la dependencia de OpenLayers.Geometry.Point y mi versión ahora funciona en objetos js simples con los atributos x, y.

Sus opciones son, en 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 se acerque la cantidad de características del lado del cliente, se limitará a las personas visibles en esa medida, en lugar de a todas.

Como segunda opción, podría considerar escribir un Vector / Renderer 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 funciones en el lado del servidor para que los puntos cercanos se fusionen en uno solo, lo que nuevamente reduce el número de funciones dibujadas. .

    
respondido por el unicoletti 08.01.2012 - 17:51
0

Utilizando UTFGrid y TileMill puedes mostrar puntos ilimitados con bastante buen rendimiento. 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 otra 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 un montón de baldosas.

    
respondido por el tmcw 11.01.2012 - 16:53

Lea otras preguntas en las etiquetas