-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Vega] user should be able to set a specific tilemap service using the mapStyle property #88440
Conversation
784db1f
to
60b5565
Compare
4bcb7c1
to
43bfdf7
Compare
Pinging @elastic/kibana-app (Team:KibanaApp) |
@elasticmachine merge upstream |
1 similar comment
@elasticmachine merge upstream |
// Can be set to one of the following: | ||
// - set to false to disable base layer; | ||
// - set to "default" to use Kibana's default base map layer; | ||
// - set "mapStyle" to any Elastic Maps Service (EMS) tile layer id. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about listing out valid tile layer ids here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we cannot guarantee that this doc will be updated on updating available EMS layers =)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is OK, and we can remove once elastic/ems-landing-page#304 is fixed and there is an easy way for users to get the ids from EMS. I will add a comment in elastic/ems-landing-page#304 to update these docs to link to available EMS baselayer ids once they are available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not a big fan of hard coding that id's. I see that currently for some reasons maps_legacy/ServiceSettings
returns only road_map
and in case if user set the value of map.tilemap.url
I also see TMS in config/kibana.yml
in that array:
I prefer to keep this message as it for now. But in parallel we are working on migration leaflet -> mapbox
#88605 where we use @elastic/ems-client directly. So very soon "road_map_desaturated" and "dark_map" will be also available.
The goal of that PR is to remove wrong if
statement from vega_parser.ts
.
defaultMessage: '{mapStyleParam} was not found', | ||
values: { mapStyleParam: `"mapStyle":${mapStyle}` }, | ||
defaultMessage: | ||
'{mapStyleParam} was not found. Set to "default" to use Kibana\'s default base map layer or set to "false" to disable base layer', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about listing out EMS layer ids when EMS is enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do it, but from the other hand I don't like how our current vega warning messages looks like. It's just a text without any formatting. I would not like to overload these messages with this information. But if you insist I'll do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
far enough, maybe just putting the EMS ids in the docs then
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @alexwizp
I agree that it would be useful for Vega-users to set custom baselayers (either with map.tilemap.url or by explicitly setting the EMS-layer).
I'm not sure if I'm in favor of overloading the mapStyle
parameter to this extent.
- `it overloads the mapStyle parameter to now expect three types
- boolean
false
- string
default
- layer-id (which is an enumeration published by EMS)
The end-user behavior in the context of Kibana would end up being quite complicated:
mapStyle | no map.tilemap.url | map.tilemap.url: foobar/{x}/{y}/{z} |
---|---|---|
false | .no basemap | no basemap |
undefined | auto-switch road_map/dark_theme from EMS | use foobar/{x}/{y}/{z} |
default |
auto-switch road_map/dark_theme from EMS | use foobar/{x}/{y}/{z} |
ems layerId enumeration | use the EMS layerId | use the EMS layerId |
- Overloading mapStyle puts implicit constraints on EMS
This change puts a constraint on EMS. EMS can not introduce a layer called default
. Minor, but it is contextual knowledge we then need to maintain going forward.
Rather, my 2c would be to keep this change more minimal.
- Is it possible to start with improving the behavior of
default
?
This would just take into account whether maps.tilemap.url
is set. This would align the behavior of Vega with how it is in the Maps-app or in the region and tile-map visualizations.
- To introduce the ability to set the EMS layerId, I would do this by adding a new parameter, instead of overloading the
mapStyle
value.
For example something like:
mapStyle: default
mapStyle: false
mapStyle: ems
emsTileLayerId: dark_theme
For (2), we should start taking into account whether connection to EMS has is been turned off explicitly. Once the mapbox-migration is complete, we can also will need to check whether the on-=rem setup is correct and the license is valid. This then can be surfaced into the warning message.
I think (1) would be a good first step, but for (2), I would wait until the mapbox-migration is complete. Given all the little edge-cases that (2) might introduce, it's probably something Maps-team should take on as well.
thanks, let me know what you think.
@thomasneirynck from my perspective If we remove And I agree with you, let's get back to this PR after we finish with #88605. |
…e mapStyle property
9ef4209
to
253e661
Compare
@elasticmachine merge upstream |
@elasticmachine merge upstream |
PR updated as recommended by @thomasneirynck |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works fine and the code is LGTM, my only concern is that is it a breaking change. Not a huge one but the users that have the mapStyle on default
should change it to true. Otherwise they will see an error on the vega maps. So maybe a migration script could be a good solution here? Of course, the vega maps are on experimental phase so we could omit this. I would love your feedback on that @thomasneirynck @nreese
If its possible to write a migration script, then this PR should add one. We should strive to make upgrading between minors as seamless as possible. |
I think we can, @alexwizp do you want to also take care of this? |
+1 on migration script, but imho I think the breaking change is fairly minor, and given that this is an experimental feature, it's imho something we could live with. We can also remove I don't feel strongly either way. |
@elasticmachine merge upstream |
@stratoula @thomasneirynck Let me clarify a little. Currently if user set value for I'm not a big fan of creating a migration script for that. I see some difficulties on JSON cause on parse/stringify specs with the 'default' value we lose user comment and formatting. Probably we can replace value using the regular string functions. But not sure if it's worth it.... |
This means, that the map will load, right? And the user will see a warning. Ok I am fine with it if the map team agrees 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx @alexwizp. This is a nice addition, and thanks a lot for the API cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👏
# Conflicts: # src/plugins/vis_type_vega/public/vega_view/vega_map_view/view.ts
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…e mapStyle property (elastic#88440) * [Vega] user should be able to set a specific tilemap service using the mapStyle property * Update vega-reference.asciidoc * fix PR comments * rename mapStyle -> emsTileServiceId Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…timeline-and-rollover-info * 'master' of github.com:elastic/kibana: (47 commits) [Fleet] Use TS project references (elastic#87574) before/beforeEach clean up (elastic#90663) [Vega] user should be able to set a specific tilemap service using the mapStyle property (elastic#88440) [Security Solution][Case] ServiceNow SIR Connector (elastic#88655) [Search Sessions] Enable extend from management (elastic#90558) [ILM] Delete phase redesign (rework) (elastic#90291) [APM-UI][E2E] use withGithubStatus step (elastic#90651) Add folding in kb-monaco and update some viewers (elastic#90152) [Grok Debugger] Changed test to wait for grok debugger container to exist to fix test flakiness (elastic#90543) Strongly typed EUI theme for styled-components (elastic#90106) Fix vega renovate label (elastic#90591) [Uptime] Migrate to TypeScript project references (elastic#90510) [Monitoring] Migrate data source for legacy alerts to monitoring data directly (elastic#87377) [Upgrade Assistant] Add A11y Tests (elastic#90265) [Time to Visualize] Adds functional tests for linking/unlinking panel from embeddable library (elastic#89612) [dev-utils/ship-ci-stats] fail when CI stats is down (elastic#90678) chore(NA): remove write permissions on Bazel remote cache for PRs (elastic#90652) chore(NA): move bazel workspace status from bash script into nodejs executable (elastic#90560) Use default ES distribution for functional tests (elastic#88737) [Alerts] Jira: Disallow labels with spaces (elastic#90548) ... # Conflicts: # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/components/timeline/timeline.tsx # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/lib/absolute_timing_to_relative_timing.test.ts # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/lib/absolute_timing_to_relative_timing.ts
…e mapStyle property (#88440) (#90745) * [Vega] user should be able to set a specific tilemap service using the mapStyle property * Update vega-reference.asciidoc * fix PR comments * rename mapStyle -> emsTileServiceId Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This is a PR continued discussion of the next comment
Originally posted by @alexwizp in #88316 (comment)
For people who will check these changes:
To test that changes please follow next steps:
Kibana
instance with the following configuration property:map.tilemap.url: http://c.tile.stamen.com/watercolor/{z}/{x}/{y}.jpg
You can use the following spec for testing:
Apply changes and see which tile map layer was applied.

Expected screen:
Set mapStyle option to false

Expected screen:
Set emsTileServiceId option to

dark_map
. It's one of our default layers. Be sure thatmap.includeElasticMapsService
configuration property is trueExpected screen: