¿Crear polígonos vectoriales con rendimiento de representación como GISCloud?

59

He estado buscando una solución sólida que me permitiera crear un mapa web y superponer polígonos vectoriales sin demorar mucho en cargar dichos datos con el objetivo de permitirme hacer que cada polígono muestre un color diferente en un evento de desplazamiento.

Hasta donde sé, hay 3 opciones específicas para lograr esto a través de lienzo, SVG, Flash.

Parece que Flash sería la mejor solución si funcionara en iPhones / ipads de Apple, ya que parece proporcionar la representación más rápida y la pantalla más limpia. El lienzo parece ser la segunda mejor opción, pero lleva mucho tiempo si tiene cientos de polígonos que se muestran en un mapa, mientras que SVG tarda aún más en renderizarse.

Yo casi perdido la esperanza de encontrar una solución a este problema , pero hoy me encontré con una compañía llamada GISCloud http://www.giscloud.com (actualmente en beta con inscripción gratuita).

Esta empresa, ALGUNA VEZ, logró encontrar una forma increíble de representar cientos de vectores en un mapa en tiempo casi real. Me sorprendió su enfoque y mi pregunta a la comunidad se relaciona con la forma en que podemos replicar su enfoque para usarlo con tecnologías existentes como folletos, capas abiertas, cera ...

Echa un vistazo por ti mismo viendo esta increíble demostración: http://www.giscloud.com/map/284/africa

Asegúrese de pasar el cursor sobre cualquiera de los polígonos de la página y pruebe los controles de zoom para ver que estos polígonos son vectores.

Lo que he notado al mirar las solicitudes con firebug es que el mapa está solicitando archivos json específicos. Parece que, dependiendo del nivel / área de zoom, se solicitan varios archivos json.


También debería mencionar aquí que una vez que giscloud carga los datos en la página que se cierne sobre un vector, cambia inmediatamente el color sin crear una nueva solicitud.

EJEMPLOS

Supongo que la estructura de la URL sigue la lógica estándar del servicio de mosaico (por ejemplo, la tercera a la última carpeta es el nivel de zoom ...).

En cualquier caso, he analizado los datos reales de estos archivos json y parece que la lógica que están utilizando sigue algún tipo de lógica mediante la cual crean sus vectores basados ​​en estos valores de datos:

  • ancho / alto: definen el ancho y alto de los datos que se sirven en cada solicitud json
  • píxeles: aquí definen valores de píxeles que supongo que de alguna manera se relacionan con algunas coordenadas generales de píxeles x / y para niveles de puntos generalizados. Supongo que de alguna manera tienen una forma de simplificar automáticamente la región según el nivel de zoom. Supongo que mediante el uso de coordenadas de píxeles, supongo que están reduciendo drásticamente el tamaño de los datos que deben cargarse en comparación con los datos de lat / long.
  • estilos: aquí definen dos valores css RGB. "F" representa el color del archivo poligonal y "S" representa el color del borde del polígono.
  • geom: aquí es donde supongo que de alguna manera están definiendo específicamente la definición de cada polígono dentro del mosaico que se está cargando donde dichos datos se definen en función de la ventana del contenedor del mapa. Lo que también es interesante es que cada entrada tiene un valor "S" que supongo que se usa como un atributo opcional o un valor de enlace de característica y al final de cada entrada aquí hay un área que parece definir un ID por vector específico junto con el ID de capa que supongo se utiliza para unir de alguna manera los datos de cada solicitud de mosaico json que se llama.

También estoy asumiendo que de alguna manera han descubierto una manera de determinar y dividir automáticamente los datos que deben cargarse para cada mosaico, dependiendo del tamaño de los datos que deberían cargarse para el mosaico solicitado.

Aquí hay un desglose extraído de una de estas solicitudes:

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

¿Cómo podemos replicar el mismo tipo (o similar) de velocidad usando postgis (que es lo que parecen estar usando también)?

NetConstructor.com
fuente
Ah! No mire el archivo JSON, mire las otras imágenes aparentemente sin importancia que se pasan :) Vea mi respuesta a continuación.
Ragi Yaser Burhum
"hay 3 opciones específicas" ... Entonces, ¿qué es Silverlight, hígado picado ?
Kirk Kuykendall
Silverlight requiere su complemento para funcionar y no creo que sea realmente más rápido que la solución que usa giscloud, pero no he hecho ninguna comparación directa.
NetConstructor.com
2
Esta pregunta presenta muchas cosas interesantes de las que hablar que no se ajustan al formato habitual de preguntas y respuestas. Hablemos sobre ellos en Uso de vectores en un mapa web mundial
matt wilkie
@RagiYaserBurhum Hay una buena explicación de cómo se usó para el mapeo de isócronas de viaje utilizando una técnica similar: mysociety.org/2012/11/08/…
djq

Respuestas:

56

He visto esta técnica utilizada en el pasado. Me lo explicó Zain Memon (de Trulia), quien ayudó a dar su opinión cuando Michal Migurski estaba creando TileStache. Zain lo revisó mientras explicaba su demostración de Trulia que usa esta técnica en una de nuestras reuniones más antiguas de SF GeoMeetup hace algún tiempo . De hecho, si estás en San Francisco la próxima semana (este es mi intento flojo en un enchufe, él tocará esto , así que siéntete libre de presentarte :)

OK, ahora a la explicación.

Primero, está mirando un poco en el lugar equivocado cuando mira los archivos json de arriba.

Déjame explicarte (tan breve como pueda), por qué.

Los mosaicos se pasan como mosaicos renderizados normales, no es gran cosa allí, sabemos cómo hacerlo y, por lo tanto, no necesito explicar eso.

Si lo inspeccionas en Firebug, verás que también obtienes un montón de imágenes que parecen estar en blanco, como esta .

¿Por qué está en blanco? No lo es. Los píxeles contienen datos, simplemente no datos tradicionales de imágenes visibles. Están utilizando una técnica muy inteligente para pasar datos codificados en los mismos píxeles.

Lo que ha estado sucediendo en la última década es que la gente ha estado intercambiando datos de legibilidad y portabilidad de formatos a expensas de la eficiencia del almacenamiento.

Tome este ejemplo de datos de muestra xml:

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

OK, ¿cuántas mordidas para transferir esto? Siempre que seamos utf8 (1 byte por carácter cuando se trata con este contenido). Bueno, tenemos alrededor de 176 caracteres (sin contar tabulaciones o espacios), lo que hace que estos 176 bytes (esto es optimista por varias razones que omitiré por simplicidad). Eso sí, esto es por 2 puntos!

Aún así, un asno inteligente que no entiende de qué está hablando, en algún lugar, afirmará que "json te da una mayor compresión".

Bien, pongamos las mismas tonterías xml que json:

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

¿Cuántos bytes hay aquí? Decir ~ 115 caracteres. Incluso hice trampa un poco y lo hice más pequeño.

Digamos que mi área cubre 256x256 píxeles y que tengo un nivel de zoom tan alto que cada entidad se representa como un píxel y tengo tantas funciones que está llena. ¿Cuántos datos necesito para mostrar que 65,536 características?

54 caracteres (o bytes utf, e incluso estoy ignorando otras cosas) por entrada de "función" multiplicada x 65,536 = 3,538,944 o aproximadamente 3.3MB

Creo que te haces una idea.

Pero así es como transportamos datos en una arquitectura orientada a servicios. Basura legible hinchada.

¿Qué pasa si quisiera transportar todo en un esquema binario que inventé yo mismo? Digamos que, en cambio, codifiqué esa información en una sola imagen de banda (es decir, blanco y negro). Y decidí que 0 significa vendido, y 1 significa disponible, y 2 significa que no lo sé. Heck, en 1 byte, tengo 256 opciones que puedo usar, y solo estoy usando 2 o tres de ellas para este ejemplo.

¿Cuál es el costo de almacenamiento de eso? 256x256x 1 (solo una banda). 65,536 bytes o 0.06MB. Y esto ni siquiera toma en consideración otras técnicas de compresión que obtengo gratis de varias décadas de investigación en compresión de imágenes.

En este punto, debería preguntarse por qué las personas no simplemente envían datos codificados en formato binario en lugar de serializar a json. Bueno, primero, resulta que javascript es un gran momento para transportar datos binarios , por eso la gente no ha hecho esto históricamente.

Algunas personas utilizaron un trabajo increíble cuando aparecieron las nuevas características de HTML5, particularmente el lienzo . Entonces, ¿cuál es esta increíble solución? Resulta que puede enviar datos a través del cable codificado en lo que parece ser una imagen, luego puede insertar esa imagen en un lienzo HTML5, lo que le permite manipular los píxeles directamente . Ahora tiene una forma de obtener esos datos, decodificarlos en el lado del cliente y generar los objetos json en el cliente.

Detente un momento y piensa en esto.

Tiene una forma de codificar una gran cantidad de datos georreferenciados significativos en un formato altamente comprimido, órdenes de magnitud más pequeños que cualquier otra cosa que se haga tradicionalmente en aplicaciones web, y manipularlos en JavaScript.

El lienzo HTML ni siquiera necesita ser usado para dibujar, ¡solo se usa como un mecanismo de decodificación binaria!

De eso se tratan todas esas imágenes que ves en Firebug. Una imagen, con los datos codificados para cada mosaico que se descarga. Son súper pequeños, pero tienen datos significativos.

Entonces, ¿cómo codifica esto en el lado del servidor? Bueno, debe generalizar los datos en el lado del servidor y crear un mosaico significativo para cada nivel de zoom que tenga los datos codificados. Actualmente, para hacer esto, tiene que implementar el suyo: no existe una solución de código abierto lista para usar, pero tiene todas las herramientas que necesita para hacerlo. PostGIS hará la generalización a través de GEOS, TileCache se puede usar para almacenar en caché y ayudarlo a activar la generación de los mosaicos. En el lado del cliente, necesitará usar HTML5 Canvas para pasar los "mosaicos falsos" especiales y luego puede usar OpenLayers para crear objetos javascript reales del lado del cliente que representan los vectores con efectos de mouse.

Si necesita codificar más datos, recuerde que siempre puede generar imágenes RGBA por píxel (que le da 4 bytes por píxel o 4,294,967,296 números que puede representar por píxel ). Puedo pensar en varias formas de usar eso :)

Actualización : Responde la pregunta QGIS a continuación.

QGIS, como la mayoría de los otros GIS de escritorio , no tiene un conjunto fijo de niveles de zoom. Tienen la flexibilidad de hacer zoom a cualquier escala y solo renderizar. ¿Pueden mostrar datos de WMS o fuentes basadas en mosaicos? Claro que pueden, pero la mayoría de las veces son realmente tontos al respecto: Zoom en una medida diferente, calcular el cuadro delimitador, calcular el mosaico requerido, agarrarlos, mostrarlos. La mayoría de las veces ignoran otras cosas, como cachés de encabezado http que lo harían para que no tuvieran que volver a buscar. A veces implementan un mecanismo de caché simple (almacene el mosaico, si lo solicita, verifique el mosaico, no lo solicite). Pero esto no es suficiente.

Con esta técnica, los mosaicos y los vectores deben volverse a buscar en cada nivel de zoom . ¿Por qué? Porque los vectores se han generalizado para acomodar los niveles de zoom.

En cuanto al truco completo de colocar los mosaicos en un lienzo HTML5 para que pueda acceder a los búferes, todo eso no es necesario. QGIS le permite escribir código en Python y C ++, ambos lenguajes tienen un excelente soporte para manejar buffers binarios, por lo que esta solución es realmente irrelevante para esta plataforma.

* ACTUALIZACIÓN 2 **:

Hubo una pregunta sobre cómo crear los mosaicos de vectores generalizados en primer lugar (primer paso para bebés antes de poder serializar los resultados en imágenes). Quizás no aclare lo suficiente. Tilestache le permitirá crear "mosaicos vectoriales" efectivos de sus datos en cada nivel de zoom (incluso tiene una opción que le permite recortar o no recortar los datos cuando pasa el límite del mosaico). Esto se encarga de separar los vectores en mosaicos en varios niveles de zoom. Elegiría la opción "no recortar" (pero elegirá un mosaico arbitrario donde cubra más área). Luego puede alimentar cada vector a través de la opción de generalización GEOS con un gran número, de hecho, desea que sea lo suficientemente grande como para que las polilíneas y los polígonos colapsen sobre sí mismos, porque si lo hacen, puede eliminarlos del nivel de zoom ya que para esa etapa son irrelevante. Tilestache incluso le permite escribir proveedores de datos pitónicos fáciles donde puede poner esta lógica. En esa etapa, puede elegir servirlos como archivos json (como lo hacen con algunas de las muestras de mapas africanos) o como geometrías serializadas en los png, como lo hacen en otras muestras (o la de Trulia) que di anteriormente.

Ragi Yaser Burhum
fuente
2
Hasta ahora, cada persona que he visto usando esta técnica no ha publicado el código. En mi humilde opinión, porque la parte importante realmente está sucediendo en el servidor y no hay un "estándar" para esto y porque elegir lo que significa cada píxel (1 = vendido, 2 = disponible, etc.) es tan específico para su mapa actual que este código es lo más probable es que no sea "genérico".
Ragi Yaser Burhum
1
En cuanto a QGIS, la respuesta es un poco más complicada, actualizaré mi respuesta en el camino al trabajo. No se asuste, tomo un tren, así que no conduzco mientras respondo a GIS.SE para mí :)
Ragi Yaser Burhum
12
+1 Gracias por no comprimir esta respuesta muy legible :)
Kirk Kuykendall
1
Puede hacer esto con Silverlight o Flash con seguridad. Sin embargo, recuerde que la parte importante está ocurriendo en el servidor para Flash o Silverlight no serían de que gran parte de la ayuda.
Ragi Yaser Burhum
2
Cuatro años después, hay muchas cosas que han evolucionado y este cuadro de texto solo tiene ~ 500 caracteres para explicarlo. El resumen es que WebGL es maduro y, más allá de las técnicas de serialización, la gente ha estado aplicando codificación delta de precisión fija (como solíamos hacerlo en los años 60) en formatos como Topojson. Esta es una buena cosa. Me encantaría ver algunas de estas cosas en los estándares de la OGC ... sin embargo, la política en torno a la OGC ha sido muy compleja últimamente. Aquí están mis sentimientos de hace dos años: blog.burhum.com/post/50036141569/the-ogc-is-stuck-in-1999
Ragi Yaser Burhum
23

Directo del desarrollador Dino Ravnic en una publicación reciente de la lista de correo :

No es un gran secreto cómo lo hicimos, así que estaría feliz de compartirlo con ustedes ... la clave está en dos cosas:

  1. eliminar de un mosaico todos los vectores que son demasiado pequeños para ser visibles, es decir, su área cuando se calcula en píxeles es inferior a 1px. así que dejamos caer tal vector y en lugar de él colocamos un píxel, por lo tanto, hay una propiedad "píxeles" en nuestro mosaico json

  2. los vectores que serán realmente visibles se generalizan y luego se escriben en un mosaico con sus coordenadas en píxeles

En la parte del cliente, representamos en el lienzo esos píxeles estáticos y vectores visibles. Además de los vectores, implementamos el manejo de eventos del mouse para lograr el desplazamiento, es decir, la interactividad. y eso es.

Nuestro motor de mapas backend hace todo el trabajo pesado porque no usamos ningún precaching y todas las fichas se generan sobre la marcha. Es muy importante para nosotros tener un mapa que pueda actualizarse rápidamente.

Por lo tanto, parece que el lado del cliente es la parte fácil. Es impresionante que los datos se procesen sin almacenamiento en caché.

También menciona un servicio de alojamiento que puede ser de su interés. Es posible que desee sopesar el costo de intentar recrear esto con el costo de usar un servicio listo para usar.

geographika
fuente
La parte que me confunde aquí es que parece que se están enviando solicitudes a postgis y, en lugar de obtener geojson estándar con valores de lat / long, parecen estar (en tiempo real) convirtiendo los valores de lat / long en coordenadas xyz y escupiéndolos según el nivel de zoom y los mosaicos del mapa necesarios. ¿Qué creen ustedes que se está utilizando para obtener estas velocidades?
NetConstructor.com
@netconstructor ¿Tal vez la geometría ya está almacenada en geometría xyz, así que no es necesario convertir?
geographika
Las coordenadas xyz relativas son probablemente más cortas que las lat / long relativas y necesitan menos ancho de banda.
Matthew Snape
bien, pero están convirtiendo esos datos sobre la marcha
NetConstructor.com
17

Como describí en la lista OSGeo, la clave está en entregar datos como mosaicos vectoriales JSON que tienen píxeles para la geometría de subpíxeles y geometría generalizada para aquellas características que serán realmente visibles en cierto nivel. El rendimiento es excelente porque esta técnica elimina toda la información vectorial innecesaria y deja solo aquellos vectores que realmente tendrán un impacto visual en el mapa. Los píxeles están ahí para llenar los huecos y colocarse en lugar de esos vectores de subpíxeles. Eso es todo con respecto al formato de mosaico.

En el lado del backend está el verdadero trabajo pesado. No estamos utilizando TileStache ni ningún otro motor de mapas, ya que escribimos el nuestro que puede, con varias optimizaciones, producir tales gráficos vectoriales en tiempo real.

Primero, comenzamos a entregar mosaicos de mapas como SWF y, últimamente, habilitamos la salida a JSON para poder usar HTML5 Canvas para representar los gráficos. A continuación puede encontrar un punto de referencia que compara este tipo de tecnología vectorial con tecnología raster (mapnik). Para una comparación justa, solo busque resultados en modo CGI.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

Estamos planeando proporcionar esta tecnología como un servicio de alojamiento de mosaicos de mapas. La idea es alojar sus datos geográficos en la nube y, a través de HTML5, entregarlos en cualquier cliente de mapas a alta velocidad, sin necesidad de precachear los mosaicos. Si está interesado en unirse a esta versión beta, no dude en contactarnos aquí: http://www.giscloud.com/contact/

Dino Ravnic
fuente
1
La idea de usar mosaicos para datos vectoriales es muy interesante (parece otra redacción para "indexación espacial"). ¿Cómo manejas las características que cruzan varios mosaicos? ¿Están cortados?
julien
3
sí, los vectores se recortan contra el mosaico
Dino Ravnic
14

Parece que recientemente se hizo una pregunta muy similar en el foro OSGeo Open Layers , con los desarrolladores de GIS Cloud describiendo su enfoque, que es una mezcla interesante de geometrías GeoJSON y píxeles estáticos. En realidad, generan todos los mosaicos de vectores sobre la marcha en lugar de usar un caché preconstruido de archivos GeoJSON.

Esri ha implementado un enfoque similar, utilizando ArcGIS Server y Feature Layers , que pueden generalizar las geometrías sobre la marcha y enviarlas por cable como JSON.

Para un método directo que realmente puede implementar ahora, puede construir mosaicos vectoriales con Tilestache (que tiene soporte PostGIS ) y consumirlos en Polymaps . Polymaps usa SVG, pero el rendimiento es bastante bueno , y las reglas CSS para diseñar elementos de mapa, por lo que la representación de características depende totalmente de usted. Aquí hay una publicación de blog que trata sobre algo similar a lo que está preguntando.

wwnick
fuente
1
@wwnick: gracias por su respuesta, pero parece que GisCloud.com está utilizando algunos métodos adicionales que les permiten un poder de procesamiento increíble sin tener que almacenar en caché los elementos, lo que significa que todo es en tiempo real. Agregué una recompensa a la pregunta y esperaba que estuvieras dispuesto a participar para proporcionar una solución en profundidad. ¡Gracias por tu respuesta hasta ahora!
NetConstructor.com
6

Jugué con OpenLayers usando Canvas y obtuve resultados razonables.

Como se mencionó en las otras respuestas: para entregar y mostrar vectores sobre la marcha, deben generalizarse para cada nivel de zoom y cada conjunto de datos. Además, puede usar la codificación de polilínea de Google para reducir considerablemente el tamaño.

Usé un mecanismo de entrega simple. Cada geometría era una función de JavaScript dentro de una respuesta HTTP de JavaScript. ¡No es tan avanzado como la entrega de vectores basada en mosaicos, pero es simple y de código abierto!

No pude probar Google Maps v3 con Canvas, pero he visto un par de demos del New York Times que me impresionaron.

menos34
fuente
El problema con este enfoque es que no es desafiante, tan rápido como su solución cuando se trata de 500.000 polígonos y es decir, el rendimiento es muy malo
NetConstructor.com
tenga en cuenta la recompensa adicional y, si puede, proporcione una solución detallada. Por cierto, el New York Times, aunque es genial, utiliza flash, a diferencia de la solución que utiliza giscloud.com.
NetConstructor.com
su enlace está fuera de línea
NetConstructor.com
Sí, lo siento, ¡mi "pasatiempo" ha llegado a su fin después de 4 años de jugar con polígonos! GISCloud le muestra cuán lejos ha llegado la tecnología desde que se publicó mi demo del censo hace unos años ... He eliminado las referencias a ella en el comentario anterior.
menos34
1
¡Bueno, mejor tarde que nunca! He actualizado las cosas para que estén tan "listas para usar" como sea posible y publiqué el código del lado del cliente en GitHub . La configuración para el nuevo código ha sido blogueada . Ahora lee los polígonos directamente de PostGIS tal como está y aplica el adelgazamiento sobre la marcha a través del marco de servicio web RESTful de PostGIS ( PRWSF ) a un cliente API de JavaScript de folleto . ¡Casi no se requiere codificación de backend!
menos34
6

No sé exactamente qué solución utiliza esta empresa (tal vez podría preguntarles directamente), pero tengo una idea.

La solución clave para mejorar la transferencia de red y la velocidad de representación de los datos vectoriales es generalizarlos de acuerdo con el nivel de zoom: la transferencia y representación a un nivel de zoom alto de miles de objetos diseñados para un nivel de zoom mucho más bajo a menudo consume mucho tiempo (y también inútil porque la pantalla final generalmente no es legible; vea, por ejemplo, esta imagen ). Para implementar eso, la base de datos del servidor postgis debe ser multiescala : para cada nivel de zoom, debe haber una representación del objeto adecuada para este nivel de zoom. Estas diferentes representaciones se pueden calcular automáticamente utilizando técnicas de generalización.. Además, los datos vectoriales enviados por el servidor al cliente no deberían depender solo de la extensión espacial, sino también del nivel de zoom: el servidor envía datos adecuados según el nivel de zoom. Este es el enfoque defendido en este excelente artículo :-)

julien
fuente
0

Hay un documento interesante, una demostración y el código fuente de un software desarrollado por Stanford Visualization Group que utiliza un cubo de datos para cada mosaico para visualizar y explorar un gran conjunto de datos geográficos. Se puede usar solo para el conjunto de datos de puntos, pero puede ser una forma interesante.

http://vis.stanford.edu/papers/immens

Vizzuality con su plataforma CartoDB y la biblioteca llamada Torque también están experimentando de alguna manera cómo dibujar un gran volumen de datos.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque

markov00
fuente