# Outlook: WFS 3.0 If you want/have to deal with **WFS version 3.0** also known as **OGC API – Features**, please forget eveything you ever learned about **XML Filter Expressions**! **Important note: You can NOT use XML Filter Expressions in order to query a WFS 3.0! That's technically impossible.** Normally, this chapter should end here, because filtering an API Features WFS needs a different approach. But as WFS 3.0 is becoming more and more popular, I'll give you some hints, how to use WFS 3.0 with FME. First of all, you'll need a service URL like this: ```url https://ogc-api.nrw.de/lika ``` Please copy and paste this URL into a web browser! The first difference is, that you'll see a GetCapabilities-like document, which is human readable (by default) and not an XML.

Beneath "***Ressources***" please click the first link in order to show the **Collections**. ``` Please note: Collections are the most important concept of WFS 3.0. ``` According to the specification (chpt. 4.1.4) a **feature collection** or **collection** is a set of features from a dataset.

**Collections** are presented the same way. You'll see a (human readable) list of feature types (sets), the service provides, e.g. * Flurstück * Flurstückspunkt * Gebäude, Bauwerk * Katasterbezirk * Nutzung * Nutzung-Flurstück * Verwaltungseinheit

Next, you may click on a feature type (set), let's say "[Flurstück](https://ogc-api.nrw.de/lika/v1/collections/flurstueck/items)", which opens a graphical preview of both 1. Geometry 2. Attributes

Is this relevant for working with WFS 3.0 in FME? To be honest: not really! But another thing is really important working with FME: the URL ```url https://ogc-api.nrw.de/lika/v1/collections/flurstueck/items ``` If you modify the URL the following way ```url https://ogc-api.nrw.de/lika/v1/collections/flurstueck/queryables ``` i.e. by replacing "***items***" with "***queryables***", you'll get a list of attributes you can use for filtering.

So, let's try it! | Key | Value | | -------------------------------------------- | ---------------------------------------- | | OGC API URL | | | *Version* | *3.0* | | Collections | flurstueck (cadastral parcel) | | Queryables | flstkennz | First, we need a different reader: **OGC API - Features (WFS 3.0)**

Next open **\[Parameters ...]** as usual. Expand **\[Constraints]** and click **\[...]** to select a collection.

Please note: if you just want to see a few features for inspecting, you can limit to number of features to read in reader parameters.

Run the reader and examine the features. ## Comparison Operators As mentioned before, it is not necessary/possible to write XML Filter Expressions to do attributive queries. You can define queries via the user interface. Just expand **\[Constraints]**, **\[Collection Query Parameters]**.

In \[**Collection(s)]** you can choose the collections, you've choosen above. In \[**Parameters]** you'll see default parameters predefined by the OGC specification, but unfortunately no service specific parameters, i.e. attributes.

But remember the **Queryables-URL**, which shows a list of attributes you can use for filtering. You can use **any attribute from the Queryables-List** as **Parameter Name**, in this case "**flstkennz**".

Tadaa! You know where we are?

And of course, you can **process a list** as discussed in [bulk-processing](https://olivers-expression-lab.gitbook.io/filter-expressions-in-fme/bulk-processing "mention") by using the **FeatureReader**-Transformer.

## Spatial Operator: BBOX As discussed in [#bbox](https://olivers-expression-lab.gitbook.io/filter-expressions-in-fme/spatial-operators#bbox "mention"), the bounding box is the swiss army knife of all spatial filters, because you can request a BBOX from the server and do the spatial operation locally in FME subsequently. Also remember the predefined **\[Collection Query Parameters]** we have seen above, especially * **bbox** * **bbox-crs** (**C**oordinate **R**eference **S**ystem) If your service comes in WGS84 (EPSG:4326) as default coordinate system, it is sufficient to pass a **comma seperated coordinate list** to the service (see [spec](https://docs.ogc.org/is/17-069r3/17-069r3.html#_parameter_bbox)): 1. lower left X, 2. lower left Y, 3. upper right X, 4. upper right Y If the default coordinate system ist **not WGS84**, you have to define the coordinate system of your bbox coordinates in **\[bbox-crs].** **Important note:** you have to use the coordinate string provided by **your** service! I.e. you can not use the string, you normally use in FME, e.g. "EPSG:25832".

bbox-crs	result
http://www.opengis.net/def/crs/EPSG/0/25832	works
EPSG:25832	will not work

To summarize:

Parameter Name	Parameter Value
bbox-crs	http://www.opengis.net/def/crs/EPSG/0/25832
bbox	367441,5620100,367619,5620254

Please compare the corresponding result shown in [#bbox](https://olivers-expression-lab.gitbook.io/filter-expressions-in-fme/spatial-operators#bbox "mention")! Ok, so far the detour to WFS 3.0. If you want to, you can play around with this: ```url https://ogc-api.nrw.de/gebref/v1/collections/gebref/ ``` ``` id: DENW36HK100076NN ```

**Caution**: please check the coordinates in Inspector ... --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://olivers-expression-lab.gitbook.io/filter-expressions-in-fme/outlook-wfs-3.0.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.