Timeline for removing legacy maps plugins

[kindsun]

Now that the new Maps app covers much, if not all of the original functionality of the legacy Maps apps with many additional features, we should consider a near-term timeline for fully removing Region and Coordinate Maps and potentially also discuss the future of Vega Maps.

A few reasons for Region & Coordinate Maps Removal:

• Some of the plugins leveraged by the legacy apps with Leaflet (i.e.- Draw, Heatmap) haven't received updates in a number of years. This was limiting when trying to fit Leaflet + plugins into a modern ES architecture in Migrate Coordinate Maps to NP #64668. And will likely grow more limiting as we move forward
• The new Maps App leverages Mapbox. This requires the Maps team to split their efforts across two very different map platforms
• It's confusing having multiple maps apps. We've removed the legacy maps docs and entries in the vis menu for basic+ license levels, this is really just the final step

Dependencies between the different maps apps have been consolidated into the new NP maps_legacy plugin, leveraged by all of the legacy maps. This should make individual removal of Region and Coordinate maps much easier. With that said, there are still a few things to consider as we move forward:

• Configuration is still highly coupled between legacy and new maps ([Maps] Decouple maps and maps_legacy config dependencies #64810)
• If we choose to get rid of Region and Coordinate maps, we still need to retain maps_legacy and the vega vis. This means our "leaflet footprint" still exists, but is substantially smaller

8.0 might be a clean line to draw for when we remove Region and Coordinate maps from Kibana but there might be broader concerns I haven't considered. Happy to discuss the plusses/minuses of this plan and adjust course as needed!

cc. @alexfrancoeur @thomasneirynck

[elasticmachine]

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

[nreese]

+1 for removal. Less code to maintain

[thomasneirynck]

thanks for raising this. +1 on proposal, and +1 on argumentation

[JacobBrandt]

I've already mentioned this to the team before but I'll say it again here. If you remove the ability to use those non OpenGL based maps you force all projects whose user base is behind thin clients with no hardware acceleration (and no opportunity to change them either) to look for a different product.

[nickpeihl]

+1 for removal.

Just a few questions:

1. With the recent updates to the new platform, could the legacy visualizations be spun off into community supported plugins?

2. Is it feasible to have an automated upgrade from legacy maps applications to Elastic Maps in v8.0?

3. I presume Vega Maps will continue to require raster tiles rather than vector tiles? So Elastic Maps Service will need to continue to provide raster tiles to support Vega Maps?

@JacobBrandt I would be curious to know which thin clients you are using with Kibana that do not support WebGL? Can you provide more details?

[JacobBrandt]

@nickpeihl Most likely decades old infrastructure that could potentially use hardware acceleration but isn't configured for it, but honestly I have no idea. It's not just the VDI hardware/infrastructure either. In some cases the user has a dedicated machine that their System Administrators refuse to install a driver for their GPU. It's not just the driver they refuse to install either but newer browser versions as well.

I'm well aware that this type of practice is not normal outside of my world but it is the world I live in and there is nothing I can do to change it. @nreese knows what I'm dealing with. I don't expect my statements to hold you back on removing these from Kibana, I just wanted you to be aware there is a community out there that uses Kibana that can't use Elastic Map.

[kindsun]

@JacobBrandt Thanks for the feedback, definitely something we can take into consideration as we move forward

@nickpeihl Good questions!

With the recent updates to the new platform, could the legacy visualizations be spun off into community supported plugins?

I'm not opposed to that. It would take a little bit of work to make each of them portable enough to stand alone but it might be worth it.

Is it feasible to have an automated upgrade from legacy maps applications to Elastic Maps in v8.0?

Yes, I would prefer that. The process might go something like this:

1. Confirm migration path for legacy map functionality to new Maps functionality and write migration
2. Create community plugin
3. Remove legacy plugin

We would still need to figure out how OSS fits here though.

I presume Vega Maps will continue to require raster tiles rather than vector tiles? So Elastic Maps Service will need to continue to provide raster tiles to support Vega Maps?

Would it? I'm not so sure. We may be doing some upcoming experimental work around a replacement for Vega Maps so this is a little TBD. As I understand it, Vega Maps has very basic bindings to leaflet to monitor panning and zooming and isn't confined to integer zoom changes. In theory, there's no reason we couldn't do with mapbox what we've already done with Vega Maps and leaflet regardless of the basemaps it uses.

[timroes]

My main question around that is: The legacy maps are OSS, while the map application is Basic. Are we planning to put a basic layer of the maps application then in OSS, or are we actually planning simply removing all maps support from OSS?

With the recent updates to the new platform, could the legacy visualizations be spun off into community supported plugins?

I'm not opposed to that. It would take a little bit of work to make each of them portable enough to stand alone but it might be worth it.

While this is technically possible, from my experience that plugin will continue to work 1 minor version with Kibana and from then on it will no longer work, until someone puts active effort into it. Peter and I had maintained some demo plugins for some time, and without having them in our build infrastructure and having active maintenance resources planned in, it's very likely they'll never be up-to-date. So while I like the idea, I just want to give that heads-up that if we put them under the Elastic umbrella, you might either need to plan significant time to keep them up to date or we have very soon an outdated plugin that's kind of "official".

[thomasneirynck]

related #71143. Consider the removal for region and coordinate maps from sample data.

[thomasneirynck]

there's two known functional gaps in Maps wrt. agg-selection in region/coordinate maps:

• ability to explicitly set size of the terms-agg ([Maps] Add size-limit to term-join metrics #71706). Unclear how useful this is, and if users actually rely on it in region-maps.
• ability to exclude results based on min_doc_count threshold ([Maps] Support custom filtering of buckets in geogrid aggregation visualizations #55520). We know this is being used in coordinate and region maps. This is advanced functionality.

Both these would be relatively minor additions to Maps (at the expense of introducing more complexity).

[nreese]

Closing. #77683 added deprecation message stating that region map and tile map will be removed in 8.0