[Maps] Remove client-side scaling of ordinal values

[thomasneirynck]

Since 7.6, styles have access to the actual min-max for numerical values. Client-side scaling to the [0-1] range is no longer necessary to create a valid mb-style rule. Maps can use the actual min/max.

This PR is a prerequisite to support dynamic-styling on non-geojson vector-sources (e.g. .mvt vector tiles). In those instances, Maps cannot get the data-ranges by cycling over the result-set, rather Maps can access them through other means (e.g. metadata request for ES-backed data, TileJson-manifest inspection, manually inputs of users, ...).

This PR has no end-user impact.

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[nreese]

I still think we need to preserve this logic and snap NaN values to less then min so they have the same behavior and do not cause errors. Also, snapping values less then min and over max need to be preserved. When using aggregations to fetch min/max, there will be values greater than and less then min/max

[thomasneirynck]

thanks, agreed.

After discussion, we're moving this clamping to the actual mb-expression. This way, we do not need to retain this separate scaleValue code-path. It has following template:

kibana/x-pack/legacy/plugins/maps/public/layers/styles/vector/style_util.js

Line 67 in 78c92a6

['max', ['min', ['to-number', [lookupFunction, fieldName]], maxValue], minValue],

[nreese]

makeMbClampedNumberExpression is not correct for empty values. to-number returns zero for null. Null should be set to lessThenFirstStopValue value and not zero

Here is an example data set to highlight the problem

PUT test
{
  "mappings": {
    "properties": {
      "location": {
        "type": "geo_point"
      }
    }
  }
}

PUT test/_doc/1
{
  "location": [0, 0],
  "prop1": 1
}

PUT test/_doc/2
{
  "location": [10, 0]
}

PUT test/_doc/3
{
  "location": [20, 0],
  "prop1": -1
}

On Master, the fill color is transparent with no value. That is the documented behavior for missing values.

In this branch, fill color is incorrectly placed in middle of ramp, because zero is in the middle of 1 and -1, when there is no value.

[thomasneirynck]

thx @nreese that example will be super helpful to work on resolving this.

[thomasneirynck]

@elasticmachine merge upstream

[nreese]

This is a great improvement and gets us one step closer to using vector tiles to display _search results. Thanks
lgtm
code review, tested in chrome

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 0257429

History

• 💚 Build #35476 succeeded 0342357
• 💚 Build #35278 succeeded e678938
• 💛 Build #34713 was flaky 55a4dfd
• 💚 Build #34410 succeeded aa49420
• 💔 Build #34306 failed 276ae43

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[thomasneirynck]

Will wait to backport to 7.x until 7.7 branch is cut. This PR has no direct user impact, and there is no reason to merge this to a released branch without actual end-user benefits.

[kibanamachine]

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

[thomasneirynck]

backport to 7.x: #61344