Vantagens do WFS sobre GeoJSON / KML?

Estou planejando criar um mapa on-line com openlayers (2 ou 3) ou folheto. Eu tenho que mostrar alguns pontos / marcadores (~ 30.000), polígonos (~ 500) e linhas no topo de um mapa OSM em várias camadas. Esses pontos e polígonos devem conter metadados (pelo menos um ID) para mostrar ao usuário informações adicionais sobre o mouse, clique ou toque em eventos. Agora estou procurando a melhor maneira de enviar esses dados para o cliente. Toda a área, onde esses recursos são colocados, é subdividida em várias seções e, na maioria das vezes, um usuário está trabalhando em uma seção (ler informações - escrever é um caso muito raro, que não será implementado no momento). Mas essas seções são colocadas próximas umas das outras e, na maioria das vezes, pelo menos 3 seções são visíveis. Os pontos também podem ser agrupados ou ocultados em um nível de zoom mais alto.

Ouvi falar do WFS, mas não vejo as vantagens sobre o GeoJSON ou o KML. Seria possível recuperar apenas os recursos dentro da caixa delimitadora da exibição atual com o WFS? Temos um banco de dados MSSQL e um serviço da web entre o banco de dados e o aplicativo da Web e, se não tiver realmente vantagens, não queremos configurar um GeoServer e um Postgres DB. Além disso, não seria um problema informar o serviço da web: dê-me todos os recursos da camada L entre X1, Y1 e X2, Y2 (como GeoJSON, KML ou o que for). Quais são as vantagens do WFS? Qual é o caminho a seguir ou que mais informações são relevantes para esta decisão?

Lembre-se de que o WFS já é um serviço que retorna seu formato de dados (mistura de padrões OGC). GeoJSON e KML são apenas um formato de dados, você precisará criar o serviço para retornar os dados.

Assim, o WFS já inclui recursos avançados de filtragem , como filtros temporais, filtros espaciais (interseção, toques, sobreposições ...), bem como operadores lógicos e de comparação ... e assim por diante. Sim, você pode especificar para recarregar os resultados de uma BBox, assim como o usuário navega no mapa. Está tudo pronto para o uso . Então, é claro, é um padrão amplamente usado que muitos servidores, clientes e aplicativos podem ler, permitindo que eles consultem esses dados automaticamente, como dito.

Portanto, a pergunta que você deve fazer é se você deseja expor esses dados a outros clientes, aplicativos e servidores? Seu serviço "Dê-me todos os recursos da camada L entre X1, Y1 e X2, Y2" será suficiente? É tudo o que você precisa? Se é tudo o que você precisa, não há razão para usar o WFS. A opção GeoJSON ou KML provavelmente será mais rápida sem toda a sobrecarga. Mas se você quiser fazer uma filtragem avançada no futuro estilo SOA, o WFS é o caminho a seguir.

Antes de tudo, recomendo que você leia as especificações . O maior profissional do WFS é que é uma maneira oficial e padronizada de acessar dados vetoriais. Isso significa que, quando você usa o WFS, não precisa reinventar a roda (por exemplo, o que deve acontecer quando duas pessoas editam o mesmo recurso ao mesmo tempo?). Também é muito mais fácil compartilhar dados pelo WFS do que usar o GeoJSON ou KML (novamente, você não precisa escrever uma função que retorne os dados solicitados pelo usuário, pois ele já faz parte das especificações do WFS).

Se você está prestes a servir camadas para acesso somente leitura, por que não usa o WMS? Deve ser totalmente aceitável para seus propósitos.

Se você tiver mais alguma dúvida, sinta-se à vontade para perguntar, eu mesmo estou decidindo esse dilema e é sempre agradável ler a opinião de outras pessoas.

O WFS oferece ao seu cliente (OpenLayers) a opção de realizar suas chamadas usando diferentes estratégias para as chamadas 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

A estratégia BBOX é comumente usada. A Camada de vetor solicitará apenas recursos do WFS que estão na viewport e, conforme a viewport é alterada, os recursos adicionais são carregados automaticamente de forma transparente.

Como o CaptDragon afirmou e mencionei na sua pergunta anterior, o número de recursos matará o OpenLayers, provavelmente, ou tornará a experiência do usuário insustentável.

Você pode inserir seus dados em um banco de dados MSSQL e, em seguida, escrever uma rotina no lado do servidor para retornar dados por meio de chamadas do Ajax e atualizar as camadas por conta própria. Seu cliente fornece os limites da viewport na chamada Ajax. O banco de dados deve estar ciente espacialmente para que isso funcione.

O WMS geraria blocos da mesma fonte de dados. A vantagem é uma implementação muito rápida, estilo do servidor e nenhum download de dados para exibição do cliente, além dos blocos. Você também pode usar o WFS com o WMS para obter informações sobre os recursos quando os usuários clicam em um ponto.

Também seria possível servir os dados de um arquivo de forma em vez de um banco de dados em todos esses cenários.