¿Ventajas de WFS sobre GeoJSON / KML?

Estoy planeando crear un mapa en línea con capas abiertas (2 o 3) o folleto. Tengo que mostrar algunos puntos / marcadores (~ 30,000), polígonos (~ 500) y líneas en la parte superior de un mapa OSM en varias capas. Esos puntos y polígonos deben contener metadatos (al menos una ID) para mostrar al usuario información adicional al pasar el mouse, hacer clic o tocar eventos. Ahora estoy buscando la mejor manera de enviar esos datos al cliente. Toda el área, donde se colocan estas características, se subdivide en varias secciones y la mayoría de las veces, un usuario está trabajando en una sección (leer información, escribir es un caso muy raro, que no se implementará en este momento). Pero estas secciones se colocan una al lado de la otra y la mayoría de las veces son visibles al menos 3 secciones. Además, los puntos pueden agruparse u ocultarse en un nivel de zoom más alto.

He oído hablar de WFS, pero no puedo ver las ventajas sobre GeoJSON o KML. ¿Sería posible recuperar las características dentro del cuadro delimitador de la vista actual con WFS? Tenemos una base de datos MSSQL y un servicio web entre la base de datos y la aplicación web y si realmente no tiene ventajas, no queremos configurar un GeoServer y un Postgres DB. Tampoco sería un problema decirle al servicio web: Dame todas las características de la capa L entre X1, Y1 y X2, Y2 (como GeoJSON, KML o lo que sea). ¿Cuáles son las ventajas de WFS? ¿Cuál es el camino que seguiría o qué más información es relevante para esta decisión?

Tenga en cuenta que WFS ya es un servicio que devuelve su formato de datos (combinación de estándares OGC). GeoJSON y KML son solo un formato de datos, tendrá que construir el servicio para devolver los datos.

Por lo tanto, con WFS se incluyen capacidades de filtrado avanzadas , como filtros temporales, filtros espaciales (intersección, toques, superposiciones ...), así como operadores lógicos y de comparación ... y así sucesivamente. Sí, puede especificar que se recarguen los resultados de un BBox y que el usuario navegue por el mapa. Todo esto está fuera de la caja . Entonces, por supuesto, es un estándar ampliamente utilizado que muchos servidores, clientes y aplicaciones pueden leer al permitirles consultar automáticamente estos datos como se dijo.

Entonces, la pregunta que debe hacerse es si va a querer exponer estos datos a otros clientes, aplicaciones y servidores. ¿Será suficiente su servicio "Darme todas las características de la capa L entre X1, Y1 y X2, Y2"? ¿Eso es todo lo que necesitas? Si es todo lo que necesita, entonces no hay razón para usar WFS. La opción GeoJSON o KML probablemente será más rápida sin todos los gastos generales. Pero si va a querer hacer un filtrado avanzado en el futuro estilo SOA, WFS es el camino a seguir.

En primer lugar, te recomiendo que leas las especificaciones . La mayor ventaja de WFS es que es una forma oficial y estandarizada de acceder a los datos vectoriales. Eso significa que cuando usa WFS, no tiene que reinventar a la rueda (por ejemplo, ¿qué debería suceder cuando dos personas editan la misma función al mismo tiempo?). También es mucho más fácil compartir datos a través de WFS que usar GeoJSON o KML (nuevamente, no es necesario que escriba una función que devuelva los datos solicitados por el usuario, ya que ya es parte de la especificación WFS).

Si está a punto de servir capas para acceso de solo lectura, ¿por qué no opta por WMS? Debería estar totalmente bien para sus propósitos.

Si tiene más preguntas, no dude en preguntar, estoy decidiendo este dilema yo mismo y siempre es agradable leer la opinión de otras personas.

WFS le da a su cliente (OpenLayers) la opción de realizar sus llamadas utilizando diferentes estrategias para las llamadas de WFS:

BBOX: reads new features when the viewport invalidates some bounds.
Cluster: for vector feature clustering.
Filter: for limiting features that get added to a layer by evaluating a filter.  The strategy maintains a cache of all features until removeFeatures is called on the layer
Fixed: requests features once and never requests new data
Paging: vector feature paging
Refresh: refreshes the layer.  By default the strategy waits for a call to refresh before refreshing.  By configuring the strategy with the interval option, refreshing can take place automatically
Save: commits newly created or modified features.  By default the strategy waits for a call to save before persisting changes.  By configuring the strategy with the auto option, changes can be saved automatically

La estrategia BBOX se usa comúnmente. La capa vectorial solo solicitará características de WFS que se encuentren en la ventana gráfica y, a medida que la ventana gráfica cambia, las funciones adicionales se cargan automáticamente de forma transparente.

Como dijo CaptDragon y mencioné en su pregunta anterior, el número de características matará a OpenLayers, lo más probable, o hará que la experiencia del usuario sea insostenible.

Puede introducir sus datos en una base de datos MSSQL, luego escribir una rutina del lado del servidor para devolver datos a través de llamadas Ajax y actualizar las capas usted mismo. Su cliente proporciona los límites de la ventana gráfica en la llamada Ajax. La base de datos tiene que ser espacialmente consciente para que esto funcione.

WMS generaría mosaicos a partir de la misma fuente de datos. La ventaja es la implementación muy rápida, el estilo del lado del servidor y la no descarga de datos al cliente para su visualización, excepto los mosaicos. También puede usar WFS con WMS para obtener información de funciones cuando los usuarios hacen clic en un punto.

También sería posible servir los datos de un archivo de forma en lugar de una base de datos en todos estos escenarios.