Features API needs a zoom parameter

[prushforth]

One of the major historical problems with WFS has been the lack of a standard approach to enabling different resolutions of feature geometry, or indeed different geometry types, based on the user's need.

I believe that the lack of a zoom level parameter in the new OGC features API is a major omission, and makes the proposed specification not only incompatible with the Spatial Data on the Web Best Practices:

This OGC standard is consistent with the OGC/W3C Spatial Data on the Web Best Practices.

but more importantly, with Web mapping in general.

Here are some relevant passages from the SDW-BP and here and here and probably others.

Please consider, at a minimum, adding a recommended zoom parameter.

[cportele]

This issue has been discussed in 2018 and it was decided that this is out-of-scope for Core, but should be a separate conformance class. Don't forget that maps are just one of the use cases. Several of the implementations support such a capability, but the conformance class was considered to be of lower priority than the current tasks approved by the OGC membership. But eventually we will get there.

See the discussion at the end of #17 and http://docs.opengeospatial.org/per/18-045.html#simplification_extension.

[jerstlouis]

This was previously requested in Testbed 13 for WFS:

http://ogc.standardstracker.org/show_request.cgi?id=514

And it is in our opinion a very important capability for any kind of large features intended to be visualized at different scales, and should be a high priority extension. I don't think this capability is specific to 'maps' or visualization.

I would go so far as arguing that the lack of this capability in WFS was one important reason that prevented its uptake compared to WMS. If WFS had a zoom level, it would have been possible for some clients to efficiently retrieve and visualize portions of large features at different scales rendered client-side.

Zoom levels are also a major reason of the success experienced by Mapbox Vector Tiles.

[prushforth]

I would go so far as arguing that the lack of this capability in WFS was one important reason that prevented its uptake compared to WMS. If WFS had a zoom level, it would have been possible for some clients to efficiently retrieve and visualize portions of large features at different scales rendered client-side.

Fully agree. Back in 2008 it was known that WFS performed badly because of the lack of control over the scale of features returned by GetFeature requests.

[PeterParslow]

As well as simplifying surfaces & curves, potentially down to points, I believe it should also thin point geometries according to some logic that is probably specific to the feature type (i.e. to the collection owner.

[jerstlouis]

@PeterParslow For that use case, in Tiles we have suggested the uses of the Styles API, where style sheets can express filtering rules by attributes.

The same could be done if we had a Features resource path after /collections/{collectionId}/styles/{styleId}/, or alternatively by having a style query parameter.

As well in our CMSS filtering language (working with Part 3 - Filtering), we have viz.sd for the scale denominator which can be used as part of filtering expressions (just like in style sheets), so that automatically by selecting a target scale, only the appropriate features are included (logical combination of viz.sd with attributes).

[prushforth]

It's been a couple of years and I was wondering if there has been any progress on this issue. I see that it's called "simplification" in the charter.