[Maps][ML] Add ML data source to Maps POC #90497
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thomasneirynck
changed the title
thomasneirynck
added
:Prototype
[Deprecated-Use Team:Presentation]Team:Geo
💔 Build Failed
Failed CI Steps
Test FailuresKibana Pipeline / general / X-Pack Visualization Wizard Tests with Lens and Maps disabled.x-pack/test/functional_vis_wizard/apps/visualization_wizard·ts.Visualization Wizard lens and maps disabled should not display lens and maps cardsStandard OutStack TraceKibana Pipeline / general / X-Pack Visualization Wizard Tests with Lens and Maps disabled.x-pack/test/functional_vis_wizard/apps/visualization_wizard·ts.Visualization Wizard lens and maps disabled should not display lens and maps cardsStandard OutStack TraceMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: |
|
@thomasneirynck - seems to be working on my end - had to update AnomalySource class to adhere to newer types but I was able to get it working locally. Would be good to catch up on which map changes will go in to support this. |
9 tasks
9 tasks
|
Closing in favor of #113857 |
24 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
POC - do not merge. This PR proposes how other plugins can register a custom data-source with the Maps-application. As an example, it uses ML.
Goal
This would be an approach to satisfy #69064, and partly satisfy #60918.
A map with two layers with ML-anomaly data, typical and actual location for anomalies
Outline:
The 3rd party plugin uses
registerSource/registerLayerWizardto register a custom source, and a custom "add layer wizard".It would look something like:
and in the MLPlugin#start-function
This plugin assumes responsibility for following content:
1. a serializable representation of the source.
Defining a serialized object that represents the source. The data-source need to be able to be fully restored from this. It is saved with the Maps saved-object.
This is equivalent to specifying a custom
SourceDescriptor, with a type.e.g.:
Typically, some UX is associated with these values so an end-user can configure these (see below).
The ability to serialize the definition of the data but not the data itself is important because then
2. the data-fetch:
Based on global-state of Kibana, particular state of the Maps-app, and particular user-configuration of the source, the correct data needs to be show.
This is done by implementing
IVectorSource.The most important method is
IVectorSource#getGeoJsonWithMeta, which returns theGeoJson, that Maps can use.There are other important methods as well, that will determine how the source is displayed in the layerTOC, which fields it exposes, whether the source-data is time-dependent, etc...
Maps provides all the tooling for end-users to symbolize this data (icons, color-ramps, etc...).
3. the "add layer wizard"-UI
This is the "card" that users would click to add a new layer.
After the user completes this wizard, the source can be added with some ready-made styling that fits the use-case. (e.g. preselect color-ramps, icon-sizes, ...)
4. the source-settings UI
These are settings of the source that can be changed after the layer has been added to the Map. They allow for more fine-grained. Some of these settings can already be part of the "add layer wizard".
These do not include settings that cannot be modified. This would include settings that would break the internal-consistency of the layer-configuration.
Initial observations:
Maps-API is not sufficiently extensible
IVectorSource-interface, they cannot take advantage of some of the utilities in Maps, a lot which are shared throughAbstract-classes in the current Maps codebase. Not exporting actual classes keeps the dependencies lean, at the expense of adding more responsibility to the plugin adding the extensions. Not sure what the correct balance would be.No explicit tie to index-patterns
This implicitly abandons index-patterns as the only mechanism which a user map data that is stored in Elasticsearch.
For example, the global search-bar may not usable for these layers. There are other instances of Map-layers where this is the case as well.