Advantages of WFS over GeoJSON/KML?

Question

I'm planning to create an online map with openlayers (2 or 3) or leaflet. I have to show some points/markers (~30.000), polygons (~500) and lines on top of an OSM map in several layers. Those points and polygons should contain meta data (at least an ID) to show the user extra information on mouse over, click or touch events. Now I'm looking for the best way to send that data to the client. The whole area, where these features are placed, is subdivided into several sections and most of the time, a user is working in one section (reading information - writing is a very rare case, that will not be implemented right now). But these sections are placed next to each other and most of the time at least 3 sections are visible. Also the points could be clustered or hidden at a higher zoom level.

I've heard about WFS, but I can't see the advantages over GeoJSON or KML. Would it be possible to just retrieve the features within the bounding box of the current view with WFS? We've got a MSSQL database and a webservice between the database and the web application and if it has not really advantages, we don't want to set up a GeoServer and a Postgres DB. Also it wouldn't be a problem to tell the webservice: Give me all features of layer L between X1,Y1 and X2,Y2 (as GeoJSON, KML or whatever). What are the advantages of WFS? What is the way, you would go or what more information is relevant for this decision?

Answer 1

Keep in mind that WFS is already a service which returns its data format (mixture of OGC standards). GeoJSON and KML are only a data format, you'll have to build the service to return the data.

So included with WFS are already advanced filtering capabilities such as temporal filters, spatial filters (intersect, touches, overlaps...) as well as logical and comparison operators...and on and on. Yes you can specify to reload results for a BBox as well as the user navigates the map. This is all out of the box. Then ofcourse it's a widely used standard that many servers, clients and applications can read by allowing them to automatically query this data as said.

So the question you should ask yourself is are you going to want to expose this data to other clients, applications and servers? Will your "Give me all features of layer L between X1,Y1 and X2,Y2" service be enough? Is that all you need? If it's all you need then no reason to go with WFS. The GeoJSON or KML option will probably be faster without all the overhead. But if you're going to want to do advanced filtering in the future SOA style, WFS is the way to go.

Answer 2

I recommend you to read the spec. The biggest pro of WFS is that it is official and standardized way to access vector data. That means when you use WFS, you do not have to reinvent to wheel (e.g. what should happen when two people edit the same feature at the same time?). It is also much easier to share data over WFS than using GeoJSON or KML (again, you do not have to write a function that returns the data user asked for as it is already a part of WFS spec).

If you are about to serve layers for read-only access, you could go with WMS. It should be totally OK for your purposes.

Answer 3

WFS gives your client (OpenLayers) the option to perform its calls using different Strategies for the WFS Calls:

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

The BBOX Strategy is commonly used. The Vector Layer will only request features from WFS that are in the viewport and as the viewport is changed, additional features are automatically loaded transparently.

As CaptDragon stated and I mentioned in your previous question the numbers of features will kill OpenLayers, most likely, or make the user experience untenable.

You could stuff your data into an MSSQL database, then write a Server Side routine to return data via Ajax calls and update the layers yourself. You Client provides the Viewport bounds in the Ajax Call. The database has to be spatially aware for this to work.

WMS would generate tiles from the same data-source. The advantage is very rapid implementation, server side styling and no downloading of data to the client for display, other than the tiles. You can also use WFS with WMS to get feature information when users click on a point.

It would also be possible to serve the data from a shape file instead of a database in all these scenarios.

Answer 4

You can do full Transactional Editing of Data (WFS-T) you can output to multiple formats Check out the newer OGC API Features specification (it will basically become WFS 3.0 but it's using JSON instead of XML and has nicer interface and pages) Crunchy Data offers pg_featureserv or GeoServer has a Community Module/Extension Check out GeoJSON-VT for leaflet that will dynamically build JSON (not binary PBF ) vector tiles so it can handle bigger data in the browser. There is also a nodejs bindings version so it can be a server-side process.