Connect to an external WFS server and render the features on the map by following these instructions:

There's always some amount of upfront work involved when creating WFS layers, as you'll need to interpret the capabilities of the service that you're trying to retrieve information from and then shape the HTTP requests accordingly.

To help us find out about the WFS service, the server normally provides an XML document outlining the capabilities of the service. As an example, the capabilities document for the WFS service that we access in this recipe can be found here at http://ogc.bgs.ac.uk/digmap625k_gsml32_cgi_gs/wfs?service=WFS&request=GetCapabilities.

Let's focus on the content of the vector source and how it influences the outcome of this recipe:

var vectorSource = new ol.source.Vector({
  format: new ol.format.WFS(),

When this vector source retrieves content from the WFS service, we inform OpenLayers what the expected format of the response will be in order to successfully parse the data and add it to the map. The format of the data will be in the WFS format, and the features will be presented in GML3 (which we specify as part of the URL string, namely output format).

You can pass an optional configuration object to the WFS format constructor, which has some properties worth mentioning, as follows:

Let's move on to the next property of the vector source configuration:

url: function(extent, resolution, projection) {
    return [
      '/proxy?proxyHost=ogc.bgs.ac.uk',
      'proxyPath=/digmap625k_gsml32_cgi_gs/wfs?',
      'service=WFS',
      'version=1.1.0',
      'request=GetFeature',
      'typename=test:uk_625k_mapped_feature',
      'srsname=' + projection.getCode(),
      'bbox=' + extent.join(',') + ',' + projection.getCode(),
      'outputformat=gml3'
    ].join('&');
  },

We manually construct the URL that will make up the AJAX request through a function assigned to the url property. This function must conform to the function type of ol.FeatureUrlFunction, which, as you see, takes extent (type ol.Extent), the map's resolution (type number) and the map's projection (type ol.proj.Projection). We can use these available arguments to dynamically build out the URL. Our function must return the URL as a string.

We are using a proxy mechanism to complete the request for us. The proxy implementation requires that we pass the host name as the proxyHost parameter, and the path name as the proxyPath parameter. If it helps, so far, we have the following endpoint: ogc.bgs.ac.uk/digmap625k_gsml32_cgi_gs/wfs?. We append further criteria to this string as query key/value pairs.

Some of the key/value pairs are static values that match up with the capabilities offered by the WFS service. These will begin to look more familiar to you once you've worked with a few different web services, such as version 1.1.0, and requests, such as GetFeature. The typename key specifies what type of feature set we're interested in. This will inevitably vary between providers.

We dynamically set the srsname key (spatial reference), which is retrieved from the map's current projection (for example, EPSG:3857). The bbox is dynamically determined from a combination of the view extent (which is originally an array converted into a comma-delimited string via the JavaScript join method) and the map's projection (projection.getCode()).

This function must return the URL as a string, so we convert the array into a string once again using the join method, which inserts an ampersand between each item in the array, conforming to the standard query string structure, that is, service=WFS&version=1.0.0.

strategy: ol.loadingstrategy.tile(ol.tilegrid.createXYZ()),

We have chosen to use a nondefault data loading strategy of tile (ol.loadingstrategy.all being the default). This makes requests and loads in features based on the tile grid with the XYZ tiling scheme. To find out more about the XYZ tiling scheme, refer to http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames. There's also a good resource that explains the difference between XYZ and Tile Map Service (TMS) tiling schemes, found here at https://gist.github.com/tmcw/4954720.

This WFS service only covers the UK, so we could optimally restrict the extent of the tile grid to the bounds of the UK so that wasteful requests are avoided. The ol.tilegrid.createXYZ class can be optionally given a configuration object, of which the extent property can be assigned an ol.Extent array that will confine the bounds of the requests. We can also specify minimum and maximum zoom levels and the tile size.

You may find that map servers that support WMS and WFS protocols can serve the same information both in raster and vector formats.

Imagine a set of regions stored in PostgreSQL/PostGIS and a map server, such as GeoServer, with a layer of countries configured to be served both as raster images via WMS requests or in the vector GML format using WFS requests.