GML, KML, GeoJSON: ¿velocidad de procesamiento de 3109 polígonos?

Estoy trabajando con Geoserver, sirviendo 48 condados de Estados Unidos inferiores a capas abiertas (3109 polígonos, muchos más vértices). Los condados se cargan en una base de datos postgis. Tengo curiosidad acerca de la experiencia del desarrollador cuando intento llevar esa cantidad de vértices al cliente.

¿Con qué formato WFS has obtenido los mejores resultados? ¿Se ha utilizado una sintonización adicional para Geoserver?

Me doy cuenta de que WMS en mosaico sería más rápido, pero quiero permitir cambios dinámicos en un mapa coroplético usando openLayers, es decir. el usuario envía un formulario, se llama un script de Python y se devuelven nuevos contenedores de datos para que las capas abiertas vuelvan a cargar el mapa div. También quiero probar esto en forma de resolución completa antes de reducir la complejidad del polígono en capas abiertas.

Tal vez esto desencadene algunas ideas nuevas: tengo una aplicación en ejecución donde los usuarios pueden editar un mapa con muchos elementos.

En lugar de enviar todos los datos como WFS, utilizo mapas WMS, y cuando el usuario hace clic o dibuja una selección, busco los elementos seleccionados como WFS .

Después de enviar una actualización al servidor, actualizo la capa WMS.

Hay algunos ejemplos de OpenLayers que demuestran cómo puedes hacer eso. Probablemente tendrá que modificarlo un poco, pero OpenLayers + GeoServer resolverá la parte difícil para usted. Los datos se envían comprimidos, por lo que el formato original ni siquiera es tan importante; No es el cuello de botella. Deje que OpenLayers y GeoServer descubran qué formato usan para intercambiar información.

Este enfoque escala bastante bien. Incluso las personas con conexiones lentas y computadoras lentas pueden usarlo para editar el mapa. Obtener cientos de elementos es muy rápido, y probablemente no necesitará más que eso al mismo tiempo para editar.

_{Finalmente ... fuera de tema, pero ya que tiene la intención de hacer cosas del lado del cliente con datos de mapas: tenga en cuenta que IE7 y versiones inferiores serán problemáticas si desea dibujar polígonos con OpenLayers. OpenLayers usa SVG para el dibujo del lado del cliente, y IE7 y versiones anteriores no tienen soporte incorporado. Esos usuarios deberán descargar un plugin viejo y malo. Todos los demás navegadores están bien.}

GEOJSON es, en mi opinión, el mejor formato, es fácil de leer, fácil de usar en JavaScript y generalmente de menor tamaño que GML / KML. Incluso puede contener información sobre el estilo, ver aquí .

No es un estándar oficial, pero es compatible tanto en folletos como en capas abiertas y en muchas aplicaciones de escritorio gis como qgis.

Usar GeoJSON es un buen comienzo para acelerar su sistema, pero puede no ser suficiente. Debería considerar construir varias versiones de su capa de datos, una por capa de zoom, y aplicar métodos de generalización / simplificación a cada versión. El cliente debe solicitar la capa relevante según el nivel de zoom seleccionado. Eso aseguraría que el nivel de detalle de los datos intercambiados entre el servidor y el cliente es adecuado, y aumentaría de manera más significativa tanto la transferencia de red como la representación. Para ir más allá, podría extender su sistema con mosaico de vectores e indexación espacial como se describe en este documento , pero no estoy seguro de que Openlayers y Geoserver puedan manejarlo ... ¡todavía!

Seguro: Olvídate de GML.

¿Por qué no utilizar su script de Python para crear un nuevo archivo SLD y enviarlo al servidor WMS con su solicitud?

Hay un ejemplo aquí .

Ya he recorrido un camino similar dos veces y la representación del lado del cliente para algo más que un pequeño número de puntos o polígonos realmente simples no es una buena idea. Una vez que se haya atado a esa arquitectura, es costoso retirarse y en cualquier proyecto es probable que vea un cambio en los requisitos o un aumento en el volumen de datos a medida que varias partes interesadas / supervisores comienzan a ver de qué es capaz su sistema. El enfoque de representación del lado del cliente basado en navegador no escala.

Si quieres renderizado dinámico, secundo el enfoque de @ iant. Anteriormente describí una serie de opciones para un problema diferente pero relacionado aquí . También utilicé la generalización de polígonos para ayudar en la representación del lado del cliente y, aunque definitivamente ayuda, genera problemas más difíciles, como si desea desplegar el polígono no generalizado a medida que el usuario se acerca más.

Incluso si está trabajando con una plataforma conocida, por ejemplo, conoce el hardware, la versión del navegador y los complementos de todos los clientes, lo cual es poco probable, no tiene idea de qué tipo de carga tienen esos clientes. Este tipo de enfoque requiere que el navegador pueda obtener MUCHO tiempo de CPU para mantener fluida la experiencia del usuario y cualquier otra cosa molestará a sus usuarios.