Support overrding default value for pagination

To a degree, we do that (see the _setDirectOverrides method). But there are certain instances where we need to derive the values if they aren't provided, so a simple override isn't always possible.

I think maybe what you are getting at is why don't we just expect the provider to send in something like:

const metadata = {
  advancedQueryCapabilities: {
    supportsPagination: true
  }
}

This is possible, but you also need to be careful that the override doesn't eliminate nested defaults, i.e., advancedQueryCapabilites needs to maintain all the other defaults but include the supportsPagination override. Certainly possible with the right code, but also not a simple override.

But I think there is a bigger issue. Nesting supportsPagination into a parent object called advancedQueryCapabilities is only appropriate in the context of the Feature Service output-plugin. It seems likely that there would or will be other output-plugins that want to know whether the underlying provider supports pagination. For those output-plugins, the advanceQueryCapabilites wrapper is an unnecessary artifact.

I think we do need a comprehensive approach for passing options/config from providers to output-plugins. But I don't think we should adopt the ArcGIS FeatureService layer-metadata structure - that would couple our own options specification to the very complex object spec determined by the ArcGIS team and it only applies to one of Koop's output-plugins.

koopjs / FeatureServer

Support overrding default value for pagination #219