The FeatureReader uses the Initiator geometry as the search envelope.

You can easily create a search envelope box to pass to the FeatureReader with e.g. the 2DBoxReplacer.

You can then set the Spatial Filter setting in the FeatureReader to e.g. "Envelope Intersects"

Optionally you can use the following method:

https://knowledge.safe.com/questions/36303/count-features-with-api.html

The Creator transformer can be the initiator for the FeatureReader.

Use the Box geometry and set the Min and Max values.

Thanks for the suggestions @erik_jan, @itay, and @david_r. I will try these out.

I need to run a process before the feature reader and I already have numerous workspace runners. I was trying to avoid nesting workbenches more than two deep.

I have been trying to use @Mark2AtSafe's suggestion to piggyback the bounding box parameters on the wfs url like below but that isn't working for me yet.

https://geo.onroerenderfgoed.be/geoserver/vioe_geoportaal/wfs?request=GetFeature&version;=1.1.0&resultType;=hits&typeName;=beschermde_archeologische_zones&srsName;=EPSG:99999&bbox;=12345,12345,12345,12345

I would rather create the box then use a workspace runner to pass the extent to the url. Not use a feature reader at all for that.

Rather then reading the entire wfs and then selecting some extent...some can be very big.

When using a FeatureReader on a WFS it will actually query the service for the data inside (if that is how you set the spatial interaction) the creator geometry, so its actually much more efficient reading and not at all reading the all service and then filtering....

Querying the service with the resultType=hits is asking the service something like: "hey! how many features are you going to return for this area (bounding box)?" which is especially handy when services have a limitation for the number of features returned per request.