Support unique bbox per feature types in WFS GetFeature

[adube]

Currently

Currently, when using the WFS format to create a GetFeature XML, you can provide a list of feature type names and a single bbox as options. As a result, we get two Query objects, one for each feature types, and the bbox ends up in the two of them.

Required feature

It would be nice to be able to define a unique bbox parameter for each feature type names.

The reason behind this is this: when querying using WFS onto point layers using a "mocked click", (i.e. we create a box with a buffer where the user clicked), we want to consider the size of the symbols as an extra "buffer" for the query. The symbols don't have the same size for each queryable layers, therefore it would make sense to have different bbox for each layer.

Proposed solution

We are aware of the "filter" option, but in our case only having the possibility to set a "bbox" for each feature types.

At the "options" level, here's how I see it. We could either:

• A) implement a new [featureTypesBBOX] option, like this:

var featureRequest = new WFS().writeGetFeature({
  srsName: 'EPSG:3857',
  featureNS: 'http://server.org',
  featurePrefix: 'server',
  featureTypes: ['points1', 'points2'],
  featureTypesBBOX: [
    [-8900000, 5380000, -8890000, 5390000],
    [-8901000, 5379000, -8891000, 5391000]
  ]
  outputFormat: 'application/json'
});

• B) implement something more oriented to have focus on each feature type:

var featureRequest = new WFS().writeGetFeature({
  srsName: 'EPSG:3857',
  featureNS: 'http://server.org',
  featurePrefix: 'server',
  featureTypes: [{
    'name': 'points1',
    'bbox':  [-8900000, 5380000, -8890000, 5390000]
  }, {
    'name': 'points2',
    'bbox': [-8901000, 5379000, -8891000, 5391000]
  }],
  outputFormat: 'application/json'
});

So, doing the above would end up supporting two different type definition for the featureTypes: strings and objects.

Thoughts

Please, let me know what you think about this Feature Request.

[ahocevar]

Sounds reasonable @adube. Feel free to contribute this improvement as pull request.

[adube]

Great, thanks. Which scenario would make more sense to you, A) or B)? A) seems simpler in my mind. Thoughts?

[ahocevar]

(B) is more intuitive from an API standpoint, and should not be much harder to implement.

[adube]

Thanks for the feedback.

[ger-benjamin]

I've opened a PR here: #11740

The second scenario (B) was likely mandatory for implementation as each bbox require a geometryName.