MapLibre Native Goals

[wipfli]

We would like to know what people's goals are with MapLibre GL Native. This started as a survey in a Google Sheet but to make it easier to discuss, I would like to port the points over to here...

Feel free to add your own goals, ask questions and give feedback, and up-vote the goals you share.

The original authors of these points are @nvanfleet, @brendan-ward, @mwilsnd, @thehoneymad, @JannikGM, and Pablo Candelas (could not find his GitHub handle, @zhangyiatmicrosoft or @drwestco do you know Pablo's handle?)

[wipfli]

Goal

Make first-time contributions easy

Motivation

MapLibre has a high-level goal of being a friendly and welcoming community. We should make sure that this manifests in low barriers for people who want to contribute for the first time.

Supported by

Oliver Wipfli (MapLibre), Brendan Ward, Swagata Prateek (AWS), Jannik (Graphmasters)

[wipfli]

Goal

Render static map images using mostly the same style.json and data sources as used in frontend mapping in maplibre-gl-js. Platforms: Linux / macOS, typically cloud-based servers without GPUs

Motivation

This enables creation of reports (e.g., PDFs) or downloadable image files on the server which embed map images alongside other content, without relying on a headless browser implementation to render maps

Supported by

Brendan Ward, Oliver Wipfli (MapLibre)

[wipfli]

Goal

Faster map load times

Motivation

Having a fast map loading is a really important feature for our users who otherwise have to wait while looking at an empty map. This is including style changes but also initial map loads

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Marc Wilson (Meta), Brendan Ward, Swagata Prateek (AWS), Jannik (Graphmasters)

[wipfli]

Goal

Animation support

Motivation

There is a strong product demand for markers that can be animated in particular ways. Having better support to do that within the SDK would be really useful. Allowing for nice animations would allow for more complicated markers that can animate when they are presented or when they are interacted with etc.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Jannik (Graphmasters)

[wipfli]

Goal

3D support

Motivation

There is some demand for features that leverage 3D models like a user puck that has a 3D arrow. Having this capability built into the SDK.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Swagata Prateek (AWS)

[wipfli]

Goal

Remove 3rd party dependencies

Motivation

Reducing compile time, licensing issues and SDK package size would be beneficial overall.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Brendan Ward, Swagata Prateek (AWS)

[wipfli]

Goal

Better code directory structure

Motivation

When working with the codebase iOS uses code from at least 5 different directories but often you must exclude some code. This can be re-organized to be a lot clearer but it's difficult without affecting a lot of different platforms who might depend on specific files. Having a cleare structure would allow for easier maintaince of build scripts.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Brendan Ward, Swagata Prateek (AWS)

[wipfli]

Goal

Have a reliabe simulator / emulator experience

Motivation

Since the last few Xcode releases iOS simulator seems to have really bad drawing and other issues. Having a reliable behavior on simulator is really important for new and old users. I believe Android has a similar problem with the emulator

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre)

[wipfli]

Goal

Cleaner codebase

Motivation

There are some pieces of code that are just not used anymore and maybe had a use case for Mapbox but don't for us. Sometimes this is even partially removed which can be confusing too. Furthermore there are a lot of really large files that are very complicated. It's hard to know where a bug lies, or where to put a new feature. This can make it hard for contributors to jump in with improvements. I have seen some OSS features with single 10,000 line files for example. Breaking out the different functionalities and making them a lot more barebones will allow for easier contribution and collaboration.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre), Marc Wilson (Meta), Brendan Ward, Swagata Prateek (AWS)

[wipfli]

Goal

Better UX for style switching

Motivation

I wish that the style switching was not so jarring.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre)

[wipfli]

Goal

Strongly typed expressions

Motivation

Using the iOS (and other platforms?) NSPredicates to form layers is really problematic and it's generally a better to have a strongly typed interface for things.

Supported by

Nathan Van Fleet (Lyft), Oliver Wipfli (MapLibre)

[wipfli]

Goal

Modular feature set

Motivation

Not all features are used by every style or production environment. An easier way to exclude unsused features will enable developers to easily reduce binary size.

Supported by

Marc Wilson (Meta), Oliver Wipfli (MapLibre), Swagata Prateek (AWS)

[wipfli]

Goal

Flexible renderer & internal rendering abstraction

Motivation

A more modularized and flexible rendering backend/abstraction allows for motivated parties to develop and maintain support for platform-specific rendering APIs that matter most to them. The ability to include a subset of available backend implementations in a build enables MapLibre to support a larger device feature set (eg: Metal on modern iOS with OpenGL fallback for legacy devices).

Supported by

Marc Wilson (Meta), Oliver Wipfli (MapLibre), Swagata Prateek (AWS)

[wipfli]

Goal

Support for noexcept environments (-fno-exceptions)

Motivation

Building without exceptions can be valuble for certain parties, including those motivated by binary size. Being able to omit exception tables and unwind information can save around 10% build size

Supported by

Marc Wilson (Meta), Oliver Wipfli (MapLibre), Jannik (Graphmasters)

[wipfli]

Goal

Removal of deprecated features from platforms and core

Motivation

Deprecated features like prefetching of tiles and annotations library in Android platform creates confusion amongst new onboarders. Removal of dead/deprecated code makes easier onboarding experience

Supported by

Swagata Prateek (AWS), Oliver Wipfli (MapLibre)

[wipfli]

Goal

A documentation website similar to MapLibre-rs

Motivation

A documentation website that contains high level components, basic theories of how MapLibre rendering works, and code hints will allow faster onboarding for new peeps

Supported by

Swagata Prateek (AWS), Oliver Wipfli (MapLibre), Jannik (Graphmasters)

[wipfli]

Goal

Offline shader build capability

Motivation

I am envisioning a world where a developer of MapLibre can use either offline or online shader compilation. This will allow a developer to have more control on binary size of the MapLibre distribution he/she produces

Supported by

Swagata Prateek (AWS), Oliver Wipfli (MapLibre), Jannik (Graphmasters)

[wipfli]

Goal

Documentation for tests

Motivation

Current unit and integration tests are near impossible to understand, modify, and maintain. A documentation on how these work, and what they are made to achieve will be very helpful for new onboardees

Supported by

Swagata Prateek (AWS), Oliver Wipfli (MapLibre)

[wipfli]

Goal

Plugin-esque architecture for Style, Map Configuration, and Data Sources

Motivation

Amazon Location Service provides map tiles from different data sources. A plugin architecture that allows modifying Style, Map Configuraiton, and Data Sources will make onboarding easier for our customers. The boilerplate to configure a map client for Amazon Location or any other provider can be reduced to a couple of lines of code.

Supported by

Swagata Prateek (AWS), Oliver Wipfli (MapLibre)

[wipfli]

Goal

Data-driven styling for the GPU

Motivation

An style-spec expression language for the GPU could be ideal for implementing animations or customizations beyond the traditional scope of mapbox, while following mapbox design principles (data-driven maps); it could also aid in supporting customizations in different rendering backends. This does not conflict with offline shader compilation if LUTs are used to drive properties in 1-3 dimensions; even with an expression-to-shader-code compiler, we'd be able to easily support new backends by implementing a few core operators in each backend.

Supported by

Jannik (Graphmasters)

[wipfli]

Goal

Shared philosophy and code structure between maplibre-gl-native and maplibre-gl-js

Motivation

Developers who are familiar with maplibre-gl-js should be able to work on maplibre gl-native and vice-versa. Code structure should be similar, so it becomes easier to implement new style-spec features in both codebases. Drift between the 2 codebases should be avoided / minimized by design. Future options to reuse the native code in the web (through WebAssembly) would be good.

Supported by

Jannik (Graphmasters)

[wipfli]

Goal

Easy to modify layer types / properties or add new ones during development, while supporting all platforms / rendering backends

Motivation

If we have to add specific rendering code for each backend for newly added layers or properties, this will make it harder to ship the same product to different platforms, as the upfront cost to finish a feature (for all required backends) will be higher.

Supported by

Jannik (Graphmasters)

[wipfli]

Goal

Globe projection support in the future

Motivation

We'll want a globe eventually, and this is where the web-map landscape has been heading for years (Google Maps / Earth and mapbox 2.x); a new rendering abstraction / backend should be able to handle this case in the future.

Supported by

Jannik (Graphmasters)

[wipfli]

Goal

Cross platform parity

Motivation

same experience across the board

Supported by

Pablo Candelas (Microsoft)

[wipfli]

Goal

Cross platform agility

Motivation

easier for the community to maintain and contribute

Supported by

Pablo Candelas (Microsoft)

[wipfli]

Goal

Performance

Motivation

Supported by

Pablo Candelas (Microsoft)