Closed rgwozdz closed 6 months ago
Latest commit: 7329e92df67d7eff2e57d8061e9b9c958b239ced
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
File Path | Statements | Branches | Functions | Lines |
---|---|---|---|---|
packages/featureserver/src/route.js | 85.71 vs 85.71 | 76.47 vs 76.47 | 100 vs 100 | 85.71 vs 85.71 |
packages/featureserver/src/query/render-features.js | 100 vs 80.95 | 100 vs 68 | 100 vs 100 | 100 vs 80.95 |
packages/winnow/src/normalize-query-options/limit.js | 100 vs 100 | 100 vs 100 | 100 vs 100 | 100 vs 100 |
packages/winnow/src/query/standard-query.js | 100 vs 94.44 | 100 vs 77.77 | 100 vs 100 | 100 vs 94.11 |
Some ArcGIS clients use
exceededTransferLimit
property on query responses to determine if they should request another page of data. The origin of the value for this field is deep in the Koop dependency chain (Winnow) where the in-memory feature collection is truncated to fit theresultRecordCount
parameter. However, pass-through providers may do their own truncation based onresultRecordCount
and as a result, never go through Winnow. In such cases,exceededTransferLimit
will always have a value offalse
, even if it should betrue
. Providers need a way of settingexceededTransferLimit: true
when they handle their own truncation.In this PR, I add the ability for data providers to control the value of
exceededTransferLimit
by adding it to the geojson metadata.