Hacia un protocolo para codificar datos vectoriales como imagen

Esta es una continuación de esta pregunta: ¿ Crear polígonos vectoriales con rendimiento de representación como GISCloud?

En su respuesta, Yagi describe una justificación para codificar información geográfica en un formato de imagen y decodificarla en el navegador. Él observa que "Actualmente, para hacer esto, tienes que rodar el tuyo". También observa que actualmente no hay un estándar para esto.

Dado el increíble rendimiento que se está demostrando, parece que la comunidad podría beneficiarse de un estándar. Desde mi comprensión del problema, parece que podría implementarse una forma estándar de tratarlo. Llámalo B-WFS.

Mi pregunta, entonces: ¿cómo sería un protocolo útil para codificar datos vectoriales como imágenes? ¿Hay algo que lo hace demasiado complejo para abordarlo de manera útil, o es solo un caso de "nadie ha hecho esto todavía"?

web-mapping vector canisrufus
fuente

Lamento mi ignorancia, tal vez no entendí el punto, pero, ¿un geotiff con tabla de colores no hace el trabajo?

Pablo

Lo siento por mi ignorancia también;) No estoy seguro de qué es una tabla de colores, pero no lo creo. El objetivo no es transmitir una imagen con los metadatos correspondientes. Como mencionas, ese es un problema resuelto. El objetivo es transmitir datos vectoriales con metadatos en un formato más compacto que UTF-8 legible por humanos. Dado que JavaScript está mal equipado para manejar datos binarios, la solución alternativa es codificar los datos en una imagen binaria y decodificarla usando HTML 5 Canvas para decodificar la imagen y luego convertirla en objetos vectoriales.

canisrufus

@Pablo Suponiendo que la E / S de la red (en lugar de analizar) es el cuello de botella en el tratamiento de vectores en la web, tener una forma establecida de tratar los vectores codificados en binario debería facilitar la escritura de mapas web de mejor rendimiento.

canisrufus

Interesante, ahora lo entiendo ... Estoy empezando a trabajar con mapas web ahora y todavía estoy aprendiendo lo básico. Por cierto, un mapa de color o clasificable es una tabla que vincula un valor de celda ráster a una clase.

Pablo

@monkut Sí, es diferente. :) Rasterizar un conjunto de vectores es solo representarlo. Voila Raster! Lo que estaba hablando en esta pregunta es diferente. Deberías leer la respuesta de Ragi en la pregunta a la que me vinculé; eso debería comenzar a explicar lo que quiero decir. Si todavía no está claro, me tomaré un tiempo para escribir una respuesta real.

canisrufus

Respuestas:

Resulta que este es un trabajo innecesario. XHR2, parte de las actualizaciones a javascript, permitirá importar y analizar datos binarios sin forzar nada.

canisrufus
fuente

No necesita ser un estándar separado como tal, porque la Especificación de Implementación WFS 04-094, cláusula 9.4 dice:

También son posibles otros formatos de salida (incluidas versiones anteriores de GML, formatos no XML, binarios y específicos del proveedor) siempre que los valores apropiados para el atributo outputFormat se anuncien en el documento de capacidades [cláusula 13]. Esta especificación recomienda que se incluya una [sic] descriptiva en el documento de capacidades para cada formato de salida enumerado allí.

La forma más fácil de agregar soporte binario es simplemente GZIP una secuencia JSON, donde la mayoría de los navegadores manejan la descompresión automáticamente. Dicho esto, no lo he probado, pero requeriría un trabajo mínimo tanto en el lado del servidor como del cliente, suponiendo que ambos ya admitan JSON sin comprimir.

MerseyViking
fuente

+1 para el punto sobre el estándar. La compresión no es codificación binaria en el mismo sentido. Vale la pena explorar las preguntas sobre las implicaciones de rendimiento entre los dos enfoques, un geojson comprimido frente a geometrías codificadas en una imagen.

canisrufus

Tiene razón, esto reduce el cuello de botella de la red, pero pone una mayor carga en el cliente y el servidor. Pero codificar datos vectoriales en una imagen es, en mi opinión, un enfoque subóptimo debido a la longitud variable de los datos vectoriales. También está ofuscando la naturaleza de los datos vectoriales. Un mejor enfoque podría ser tener dos flujos de datos paralelos, uno para vector y otro para ráster, que podrían ser manejados por diferentes servidores y dispositivos de almacenamiento y luego ser combinados por el cliente.

MerseyViking

El problema de la longitud variable de los datos vectoriales puede tratarse básicamente de la misma manera en que las redes manejan el envío de paquetes. Estoy de acuerdo en que es subóptimo, pero parece que estamos empujados a eso por el hecho de que JS no trata bien con binarios. Voy a escribir e implementar algo yo mismo, ya que tengo tiempo. Lo pondré aquí cuando tenga algo que funcione ...

canisrufus

Realmente creo que Ragi lo definió claramente en su respuesta. Estoy de acuerdo en que no lo hice. :) Puede ser que la hipótesis de que un formato binario podría ser un formato general de transferencia de datos más rápido sea incorrecta. La diferencia podría ser insignificante. Dije que "vale la pena explorar las implicaciones de rendimiento ...". Obviamente no puedo simplemente definir un formato binario y luego declarar la victoria. ¡Ya veremos!

canisrufus el

@MerseyViking Sin tener que repetir mi respuesta nuevamente, permítame poner esto en perspectiva en términos de ciclos de CPU (ya que su suposición es sobre la optimización prematura). Acceso a caché L1 = 1 ciclo de CPU, L2 = 14 ciclos, RAM ~ 250 ciclos, Disco = 41,000,000, Red (depende del ancho de banda, así que seamos amables) = 240,000,000. La E / S, ya sea basada en disco o en red (nuestro caso) es un orden de magnitud más lento. ¿Cómo se desplaza la carga de la última porción del espectro a la primera "prematura" en alguna escala?

Ragi Yaser Burhum