wip: map snapshotter

[michalgwo]

Fixes #28

I implemented snapshot functionality for Android and iOS. There is no snapshotter in the MapLibre GL JS library, so I left it empty.

I also created a demo presenting snapshot functionality.

As for iOS, as I already mentioned in my previous PRs, I don't have a Mac, so I couldn't run it, but this time I tried my best to implement it for iOS as well, but as it's not tested, and I don't have any experience with iOS, it may not work 😅 Let me know if you are not interested in fixing it, so I will remove the iOS part, and leave only Android implementation.

A few remarks about the iOS implementation:

• I wasn't sure what size should I use for CameraPosition.toMLNCamera(), so I took my shot and used the same as the size of the snapshot
• on Android cameraPosition param for snapshotter options is nullable, but on iOS it's not, I'm not sure if it's the best solution, but I made it nullable in common code and on iOS created a new empty MLNMapCamera() when cameraPosition is null
• I'm not sure about the error handling, I couldn't find any information in the documentation on what's inside the String returned on Android and NSError returned on iOS. I also failed to make the snapshotter return error, so I have no idea what kind of error is there.
• the function for converting UIImage to ImageBitmap is not written by me, I took it from this article

[sargunv]

Thanks for this! Currently planning on reviewing next week or so.

[michalgwo]

Thank you for your review, I fixed all the things you mentioned.

[westnordost]

👍

Super clean implementation

[michalgwo]

👍

Super clean implementation

Appreciate your review! Did you test it on iOS? As I mentioned, I didn't, because I don't have a Mac right now. I will probably get one in a couple of weeks, so if there is any problem, I can fix it.

[westnordost]

I didn't test anything, just read the code.

[westnordost]

That's... possible? after all, with tilt or camera rotation , the displayed area is not a bbox anymore. I'd presume that if a camera position is specified, at least if it has any rotation or tilt, the camera position takes precedence and the bbox is discarded(?) El 24 de mayo de 2025 23:09:05 CEST, "Michał Gwóźdź" ***@***.***> escribió:

…

michalgwo left a comment (maplibre/maplibre-compose#266) > That sounds like a good use case for a sealed interface! I can imagine a scenario when someone wants to set both `cameraPosition` and `region`, for example, when they have a BoundingBox of the region, but want it rotated/tilted, which needs to be set with `cameraPosition`. -- Reply to this email directly or view it on GitHub: #266 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[michalgwo]

That's... possible? after all, with tilt or camera rotation , the displayed area is not a bbox anymore. I'd presume that if a camera position is specified, at least if it has any rotation or tilt, the camera position takes precedence and the bbox is discarded(?)

According to the documentation, when region and CameraPosition are set in conjunction, the CameraPosition.target is overridden by region. I don't know how it works under the hood, but my understanding is that the other CameraPosition params like tilt, rotation, etc. are applied.

I just tested setting region (BoundingBox) with CameraPosition, which was rotated and tilted, and it works. The snapshot was rotated and tiled area from the BoundingBox. I was also trying zoom and padding, but it seems these don't have any effect on the snapshot.

[sargunv]

I just tested setting region (BoundingBox) with CameraPosition, which was rotated and tilted, and it works. The snapshot was rotated and tiled area from the BoundingBox. I was also trying zoom and padding, but it seems these don't have any effect on the snapshot.

Perhaps our parameters should be bounding box or position/zoom, with optional bearing and tilt?

[sargunv]

This, plus the attribution state stuff, is making me think the style URL and style composition should be something passed into the style state rather than into the map. And then, the user can initialize a camera + style state however they wish, and pass those two into either a map, or a snapshotter, or both

[sargunv]

Relevant comment at #374 (comment)

My suggestion to support StyleState with programmatic styling is possible in Android but not in iOS without upstream MapLibre Native changes. So I think we can merge without that for now, and file issues to request that feature upstream for MapLibre iOS.

I'll take this PR to the finish line and then release v0.9.0 and file the MapLibre Native issues. after that style state refactor.

[sargunv]

Ah nope I was wrong; programmatic styling is available in iOS: #374 (comment)

So yeah, back to the original plan to land this after our style state refactor so we can use it here.

[sargunv]

#834 integrates maplibre-native-ffi, which has a cpu readback function that works with the map texture directly. even a separate snapshotter I think will be built on that foundation now, as #572 moves to the same shared implementation

[sargunv]

thanks for taking a swing at this, and sorry it got stuck for so long!