[Maps] Use id-values from client-manifest to suggest layers

[thomasneirynck]

Summary

NOTE FOR ML-REVIEWERS: this should be a transparent change, and not require additional changes on your end. I did make simplifications under ml and data_visualizer, but no more should be needed.

---

The main purpose of this PR is to:

• avoid false positives in the maps in the data-visualizer, file-upload, and anomaly-explorer. e.g. they shouldn't show a choropleth layer with states, when the underlying data is not states.
• avoid downloading the entire GeoJson for EMS-layers in those apps. The actual geometry data is not required for the layer-suggest functionality

This uses the values-attribute from the EMS manifests, which were introduced in 7.14.

This PR removes the support for emsLayerIds. This allowed clients to explicitly check against all the fields of a layer. The downside was that the GeoJson for those layers was requested as well. This is now no longer the case.

Only joins will be suggested for fields of type id. (e.g. KY, CA, CO, NY). Fields of type name (e.g. Kentucky, California, Colorado, New York) are no longer suggested, as they are more susceptible for spelling or punctuation errors.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[nreese]

Instead of redefining interface, how about just importing FileLayerField from ems-client, https://github.com/elastic/ems-client/blob/master/src/ems_client.ts#L150

[thomasneirynck]

Agreed, but it's not exposed as main type yet elastic/ems-client#71, will change when that is updated.

[nreese]

For the time being, can you import the type like import { FileLayerField } from '@elastic/ems-client/ems_client';?

[thomasneirynck]

not quite. this is an npm dependency, and the typing dependency for the package is explicitly declared to the main file (https://github.com/elastic/ems-client/blob/master/package.json#L70). Compilation will not succeed when pointing to a "sub-module".

I'd prefer to get this addressed in ems-client first, without trying to circumvent the default import behavior.

[alvarezmelissa87]

Tested ML changes and LGTM ⚡ 🙏

[jsanz]

Tested on File Upload with a CSV airports dataset that contains region and country codes and the detection worked well 👏

[nreese]

is it possible to import "FileLayerField" with import { FileLayerField } from '@elastic/ems-client/ems_client';? I think it would be best to have a deep import then redefine the type.

LGTM
code review

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 3857ba1
• Storybooks Preview
• Documentation Changes

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
ml	1699	1698	-1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
maps	202	201	-1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
dataVisualizer	1.1MB	1.1MB	-133.0B
maps	3.1MB	3.1MB	-1.0KB
ml	5.9MB	5.9MB	-139.0B
total			-1.3KB

Unknown metric groups

API count

id	before	after	diff
maps	203	202	-1

History

• 💚 Build #133176 succeeded aac14a7
• 💔 Build #133158 failed 8161ca5
• 💔 Build #133083 failed 87e9a53
• 💔 Build #133068 failed a81035a
• 💔 Build #132836 failed 58bc237

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

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	7.x

This backport PR will be merged automatically after passing CI.