Official maplibre-compose - Evaluate and upgrade

[Archdoog]

Evaluate replacing maplibre-compose-playground with maplibre-compose for our android target. If the migration looks promising and efficient, an MR is welcome.

History

When ferrostar started, the only compose maplibre implementation was Ramani Maps. It was relatively limited at that point, so we forked and created maplibre-compose-playground to add the camera behaviors (and some other features) required for ferrostar and the turn-by-turn navigation use case.

Since then, maplibre-compose has become the official MapLibre compose library. It's got significantly more exposure, contribution, and should support most of our requirements.

Why

• Ramani Maps is MPL-2.0. We'd prefer the more permissive BSD-3 of maplibre-compose.
• Performance issues. We've had several discussions on the ferrostar weekly call.
• Collaboration. Our Ramani fork has pretty limited usage, likely only ferrostar. As a result, we're missing out on a lot of collaboration and knowledge.
• None of the core ferrostar contributors here are android first by skill 😄

Requirements

• All the basics: camera control, polyline, user puck.
• Android auto: Spike/setting up composable auto Rallista/maplibre-compose-playground#134. This isn't in ferrostar yet, but it's a short term goal and long term requirement. As a note though, it's possible the code from this PR can be moved directly to ferrostar, since there's no special maplibre stuff.
• Evaluate Implement synchronous updates for GeoJSON sources maplibre/maplibre-native#3968 to mitigate android puck lag. This would have to happen in our maplibre-compose-playground, so it also must be performant here.
• Demo app upgrade.
• Migration guide.

[bjtrounson]

Don't mind helping out with this, I recently created a Kotlin app using maplibre-compose for some more advance location mocking stuff I need to do.

[bjtrounson]

We might need to create our own custom location puck as the one that comes with maplibre-compose looks like this.

[DestBro]

We might need to create our own custom location puck as the one that comes with maplibre-compose looks like this.

They just added simple support for this, to test out, can be done better but before a refactoring is planned for the whole location-api:
maplibre/maplibre-compose#712

A costume location-puck would not hurt.

[sargunv]

Hey, I'm the maintainer of maplibre-compose. Definitely happy to answer questions or take feedback and make changes.

We're still developing the project; I'd say it's about 80-90% complete for Android and iOS, with most MapLibre functionality supported but some rough edges and small gaps. Desktop and web are far more experimental and incomplete right now.

We're in a stage where we're still open to breaking changes to refine the API (and indeed each release makes at least some small ones) so it's a good time to try it out and make sure your use case is supported well.

[klemensz]

I created a PR for the migration: #853

There are still a few known limitations documented in the PR, but overall the migration already works quite smoothly.

I switched to the maplibre-compose location puck, replacing the previous native MapLibre location puck that was implicitly provided by maplibre-compose-playground / Ramani.

The main open issue I have not solved yet is Android Auto surface gesture forwarding. The previous implementation relied on MapApplier from maplibre-compose-playground, but the new maplibre-compose stack does not seem to expose an equivalent integration point.