Skip to content
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

Why Mapbox over free and open source mapping libraries? #69

Open
abarciauskas-bgse opened this issue Mar 24, 2022 · 3 comments
Open

Why Mapbox over free and open source mapping libraries? #69

abarciauskas-bgse opened this issue Mar 24, 2022 · 3 comments

Comments

@abarciauskas-bgse
Copy link
Contributor

In response to the question "Why Mapbox?" @danielfdsilva helped provide the following explanation:


TL;DR:

  • Best match for the requirements (at the time)
  • Deep knowledge
  • Preexisting code
  • Relationship with the company

At the beginning of the project we looked at what was out there to understand if there was an alternative to mapbox (NASA-IMPACT/covid-dashboard#557).

We were looking to have different types of projections while supporting vector layers and data-driven styling.

Because we were looking for vector layer support, mapbox was a strong choice and no other library is as powerful at doing data-driven styling.

Initially it lacked projections support, but then they added them - and globe projection is coming along.

This, tied with our extensive knowledge of mapbox, and close relationship made it an easy sell.

Now, looking at what we are working with right now, it seems that vector layers are not really needed - I’m actually not sure about this, but all our conversations seem to refer to tiled datasets.

This seemingly tiny change, means we could reassess and go with a different library.


It sounds like we may consider moving to another mapping client. From what I understand there are some deal-breaker requirements (and probably some that I am missing):

  • Open source (if we're deciding not to use Mapbox, seems likely we would want to use an open source solution)
  • Support for projections required for the thematic areas of NASA's Earth Observation users (web mercator, polar, possibly others)
  • Support for 3D projections

What are some other important features we need to consider in alternatives? @danielfdsilva also mentioned data-driven styling for example.

Is CesiumJShttps://cesium.com/platform/cesiumjs) worth exploring as well?

@hanbyul-here
Copy link
Collaborator

As far as I remember, Cesium's whole elevator pitch was about 'real 3d', not extracting 2d geometries. I think it expects whole different data format, I am not sure we can render tiles from titiler in Cesium? (I have zero hands-on experience with Cesium, so please correct me if I am wrong!)

Daniel already explained about the decision to use MapboxGL well but since I often think about my faith about using MapboxGL... leaving my thoughts here.

  • I am not a big fan of MapboxGL, but it is undeniable that MapboxGL is one of very few rendering engines that has active development going on, like if there is a bug, we can expect that it is going to be fixed soonish.
  • It has enough documentation/resource so even if a new developer without much geospatial knowledge comes, I won't worry about them figuring out how to use it. (which I think important for a long term project like VEDA)
  • Using a map engine with modern UI framework (React, in our case) is sometimes tricky because each of them wants to control elements in its own ways. I am not sure MapboxGL is inherently better at being used with React, but Development Seed has accumulated institutional knowledge about it, and there are a lot of users out there who are trying to figure out similar problems.

I think it is cool that NASA is looking to use more open source libraries. I think finding alternative will likely require investing a lot more of our resource (onboarding developers, bug fix, figuring out how to use it with UI framework...) in that alternative.

@nerik
Copy link
Contributor

nerik commented Oct 27, 2022

Just reviving this because I haven't seen any mention of MapLibre. This is originally a fork of Mapbox GL v1, the project is moving at a steady pace and it is very possible that support for projections come in the future - so let's keep an eye on it.

Also, bouncing on what @hanbyul-here said:

Using a map engine with modern UI framework (React, in our case) is sometimes tricky because each of them wants to control elements in its own ways.

I've been using react-map-gl for years now, and it has been a game changer. The idea is to make Mapbox GL friendly with the declarative paradigm of React. When intensively using Mapbox GL in a React app, this makes a huge difference - avoiding having to write all that glue code (all those useEffect) which makes codebases much easier to reason about and maintain IMHO. React-map-gl is very mature and stable (part of the vis.gl suite including deck.gl), and supports both Mapbox GL and MapLibre

@nerik
Copy link
Contributor

nerik commented Nov 10, 2022

So I gave it some thoughts: https://github.com/developmentseed/how/issues/376

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants