[SIP-130] Migrating from Mapbox to MapLibre about superset HOT 15 CLOSED

Disclaimer: i'm a board member in the maplibre non-profit org

Just a note on the alternatives - deck.gl works great with maplibre-gl, to the point that latest version of kepler.gl actually has migrated entirely from mapbox-gl to maplibre-gl, for the same licensing reasons as this issue point to.

It will be helpful when implementing a typescript superset map plugin for maplibre, that maplibre-gl, in contrast to mapbox-gl, is written entirely in typescript. I believe maplibre-gl currently has all the functionality required by superset, and it's for the most part a drop-in replacement - to that end, I'd be happy to help answer any question around maplibre-gl usage and technicalities around this migration.

Some other advantages that would apply here are:

advantages over mapbox-gl v1 or a fork of it

• The maintenance burden is moved to the MapLibre org. There is paid stable maintenance on the project, and also financial investments in new feature development, so PR's /issues won't be left for dead. All this is covered by the awesome MapLibre Sponsors who all benefit from the existence of MapLibre because it allow the cost to be shared instead of covering full maintenance/development of separate forks, and it keeps an industry wide compatibility.
• Lots of performance work has been done - notably microsoft has been helping out by profiling bing maps usage extensively on the millions of users there.
• maplibre has since v3 supported webgl2 which almost all users will be using at this point, and in the increasingly rare case it's not supported there is still a webgl1 fallback in place.
• there is a growing community around maplibre-gl, we've e.g. seen a 100% increase in downloads (now ~400k/weekly) just over the past half year.
• many companies are helping out with new features related to their respective domain of expertise.
• Continous support for emergent standards, like the new datasets from the Overture Maps Foundation as shown in this example.

here are contribution graphs, with the area approx. marked after the fork, to visually represent the scale of shared continuous investments which aren't present in mapbox-gl v1:

maplibre-gl ( 2000+ PR's with bug-fixes and improvements)

advantages over mapbox-gl v2+

• maplibre-gl and mapbox-gl v1 are rendering libraries where mapbox-gl v2 is a rendering service. Both can be paired with data/styles from local files or services, but the difference is that by staying a renderer library, maplibre itself is free to use, and will run without an api key. This has multiple advantages:
  • allows rendering offline, on-prem
  • gives better startup performance, because the code doesn't "calling home" to check the api key billing status
  • It's more convenient for new users, not to have to signup for mapbox and get an api key.
• The maplibre license permits removing the logo from lower left, in case superset users rather see more of their plots.
• In case you bundle the renderer with superset, that something you can certainly do with maplibre-gl since it's just a library.

from superset.

I can start already next week, and i think the SIP looks ready.

from superset.

@rusackas , before closing it for inactivity, give me a ping. I don't mind championing the necessary work.

from superset.

It won't be closed for quite a while... I just want to make sure it's able to move forward. There are really two parts to push on:

1. Making sure the process is followed (i.e. running this SIP through the Discuss and Vote threads on the mailing list)
2. Implementing the feature.

I can certainly assist with Item 1, but would only want to do so if someone's going to follow through here. If you're game, to tackle implementation @birkskyum, I'll happily start on the more bureaucratic part ;)

from superset.

That sounds great - I'm up for taking on the implementation part.

from superset.

I think it's a good idea to split up these tasks where possible.

from superset.

@JavierMorales2 , I haven't deep dived the superset code yet, and I don't know how much different the new Data API framework is, but my guess, based on migrating plotly.js (python graphic tool) is that an initial implementation of a new plugin likely will take 2-3 weeks before it's functional, and that the following QA and release planning and preparation (docs, migration guides etc.) can require additional 1-3 months.

from superset.

I would love to see this proposal / effort move forward. @Aalbedon do you want to move this forward with a [DISCUSS] thread on the Dev mailing list? Let me know if you need any assistance with that effort.

from superset.

Checking in to see if you plan to implement this and/or carry the process through to completion, @Aalbedon. If not, this will eventually be closed due to inactivity.

from superset.

@birkskyum do you think we should limit the scope of this SIP to the Mabbox -> MapLibre migration? Then after that, we can address a DeckGL plugin migration separately? The DeckGL one seems like a more difficult task, but if you're up for it, we can leave them combined :) People will probably want to know more details about how that effort will be tackled.

I'll open the [DISCUSS] thread now, and we can start fielding such questions :)

from superset.

I should also say that unless we have feature parity (I'm not sure about that, based on the initial proposal), this would be considered a "breaking change" and would have to be held until a major version of Superset. If it's a smooth transition, I don't think it'd need to wait, but I think users would want some form a migration script in either case. @michael-s-molina has been making several of these and may be able to help point you in the right direction for that stage of the effort.

from superset.

Ok... then I think in effect, this SIP should be considered a proposal to merely to replace Mapbox with MapLibre, on the basis of all the pricing/licensing/support/modernization virtues listed above.

We can open a separate SIP for more details about each of the plugins (any revisions to control panels, migrating to typescript, talk of drilling, etc etc etc) after this general product migration is settled.

I've slightly updated the original description to address this point.

from superset.

@birkskyum do you have any idea when you might be able to jump in for the implementation part? I can put this SIP up for a VOTE now if you think it's ready.

from superset.

When could the implementation for the migration from Mapbox to MapLibre be ready?

from superset.

Vote approved! Let's do the thing!!! :D @birkskyum let us know if you need any help along the way. I'll close the issue as it's approved, but continue to track it through the rest of the SIP kanban board.

from superset.