Avantages de WFS sur GeoJSON / KML?

Je prévois de créer une carte en ligne avec des couches ouvertes (2 ou 3) ou un dépliant. Je dois montrer des points / marqueurs (~ 30 000), des polygones (~ 500) et des lignes au-dessus d'une carte OSM en plusieurs couches. Ces points et polygones doivent contenir des métadonnées (au moins un ID) pour montrer à l'utilisateur des informations supplémentaires sur les événements de la souris, du clic ou du toucher. Maintenant, je cherche la meilleure façon d'envoyer ces données au client. L'ensemble de la zone, où ces fonctionnalités sont placées, est subdivisé en plusieurs sections et la plupart du temps, un utilisateur travaille dans une section (lecture des informations - l'écriture est un cas très rare, qui ne sera pas implémenté pour le moment). Mais ces sections sont placées les unes à côté des autres et la plupart du temps, au moins 3 sections sont visibles. Les points peuvent également être regroupés ou masqués à un niveau de zoom plus élevé.

J'ai entendu parler de WFS, mais je ne vois pas les avantages par rapport à GeoJSON ou KML. Serait-il possible de simplement récupérer les entités dans le cadre de délimitation de la vue actuelle avec WFS? Nous avons une base de données MSSQL et un service web entre la base de données et l'application web et si cela n'a pas vraiment d'avantages, nous ne voulons pas mettre en place un GeoServer et une base de données Postgres. De plus, ce ne serait pas un problème de dire au webservice: Donnez-moi toutes les fonctionnalités de la couche L entre X1, Y1 et X2, Y2 (comme GeoJSON, KML ou autre). Quels sont les avantages de WFS? Quelle est la voie que vous suivriez ou quelles autres informations sont pertinentes pour cette décision?

Gardez à l'esprit que WFS est déjà un service qui renvoie son format de données (mélange de normes OGC). GeoJSON et KML ne sont qu'un format de données, vous devrez construire le service pour renvoyer les données.

Ainsi, WFS inclut déjà des capacités de filtrage avancées telles que des filtres temporels, des filtres spatiaux (intersection, touches, chevauchements ...) ainsi que des opérateurs logiques et de comparaison ... et ainsi de suite. Oui, vous pouvez spécifier de recharger les résultats pour une BBox ainsi que l'utilisateur navigue sur la carte. Tout est prêt à l'emploi . Bien sûr, il s'agit d'une norme largement utilisée que de nombreux serveurs, clients et applications peuvent lire en leur permettant d'interroger automatiquement ces données comme indiqué.

Donc, la question que vous devez vous poser est la suivante: allez-vous vouloir exposer ces données à d'autres clients, applications et serveurs? Votre service "Donnez-moi toutes les fonctionnalités de la couche L entre X1, Y1 et X2, Y2" sera-t-il suffisant? C'est tout ce dont vous avez besoin? Si c'est tout ce dont vous avez besoin, alors aucune raison d'aller avec WFS. L'option GeoJSON ou KML sera probablement plus rapide sans tous les frais généraux. Mais si vous souhaitez effectuer un filtrage avancé dans le futur style SOA, WFS est la solution.

Tout d'abord, je vous recommande de lire la spécification . Le plus grand avantage de WFS est qu'il s'agit d'un moyen officiel et standardisé d'accéder aux données vectorielles. Cela signifie que lorsque vous utilisez WFS, vous n'avez pas à réinventer la roue (par exemple, que doit-il se passer lorsque deux personnes modifient la même fonctionnalité en même temps?). Il est également beaucoup plus facile de partager des données sur WFS que d'utiliser GeoJSON ou KML (encore une fois, vous n'avez pas à écrire une fonction qui renvoie les données demandées par l'utilisateur car elles font déjà partie des spécifications WFS).

Si vous êtes sur le point de servir des couches pour un accès en lecture seule, pourquoi n'allez-vous pas avec WMS? Cela devrait être totalement OK pour vos besoins.

Si vous avez d'autres questions, n'hésitez pas à me poser, je suis en train de décider moi-même de ce dilemme et c'est toujours agréable de lire l'opinion des autres.

WFS donne à votre client (OpenLayers) la possibilité d'effectuer ses appels en utilisant différentes stratégies pour les appels 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 stratégie BBOX est couramment utilisée. Le calque vectoriel ne demandera que les fonctionnalités de WFS qui se trouvent dans la fenêtre et lorsque la fenêtre est modifiée, les fonctionnalités supplémentaires sont automatiquement chargées de manière transparente.

Comme CaptDragon l'a déclaré et je l'ai mentionné dans votre question précédente, le nombre de fonctionnalités tuera OpenLayers, très probablement, ou rendra l'expérience utilisateur intenable.

Vous pouvez bourrer vos données dans une base de données MSSQL, puis écrire une routine côté serveur pour renvoyer des données via des appels Ajax et mettre à jour les couches vous-même. Votre client fournit les limites de la fenêtre d'affichage dans l'appel Ajax. La base de données doit être spatialement consciente pour que cela fonctionne.

WMS générerait des tuiles à partir de la même source de données. L'avantage est une mise en œuvre très rapide, un style côté serveur et aucun téléchargement de données vers le client pour affichage, autres que les tuiles. Vous pouvez également utiliser WFS avec WMS pour obtenir des informations sur les fonctionnalités lorsque les utilisateurs cliquent sur un point.

Il serait également possible de servir les données d'un fichier de forme au lieu d'une base de données dans tous ces scénarios.