Repository navigation
fix: zoom 0 is a zoom, not a missing one - #11
Merged
Merged
Conversation
moveCameraTo(cameraPosition:) ran every camera through resolveCameraPosition, which read `zoom == 0 && bearing == 0 && tilt == 0` as "the caller only gave me a position" and replaced the requested camera with the stored one, keeping the position alone. A camera that really does ask for zoom 0 — the whole world — matches that test exactly, so it was the one camera the map would not move to. It shows up as a feature that does nothing rather than as a wrong value: the map stays where it was, so what that invites you to conclude is that zoom 0 is unsupported. Position-only already has a way to be said: the `moveCameraTo(position:)` overload. Inferring the same intent a second time from the *value* costs a legal zoom, and cannot tell `MapCameraPosition(position:)` from one written with `zoom: 0` anyway — zoom defaults to 0, so by the time a camera arrives the two are one value. android-sdk never had this; MapViewState.kt hands the camera straight to the controller. js-sdk-core carried the same code and loses it in the same change (MapConductor/js-sdk-core#4), so all three platforms now agree.
Merged
wf9a5m75
added a commit
that referenced
this pull request
Oct 23, 2026
* Make bearing a clockwise map rotation (#10) bearing を「値を増やすと地図が時計回りに回る」向きに統一し、ネイティブ SDK との変換をコアの CameraBearing に集約する。 * fix: zoom 0 is a zoom, not a missing one (#11) moveCameraTo(cameraPosition:) ran every camera through resolveCameraPosition, which read `zoom == 0 && bearing == 0 && tilt == 0` as "the caller only gave me a position" and replaced the requested camera with the stored one, keeping the position alone. A camera that really does ask for zoom 0 — the whole world — matches that test exactly, so it was the one camera the map would not move to. It shows up as a feature that does nothing rather than as a wrong value: the map stays where it was, so what that invites you to conclude is that zoom 0 is unsupported. Position-only already has a way to be said: the `moveCameraTo(position:)` overload. Inferring the same intent a second time from the *value* costs a legal zoom, and cannot tell `MapCameraPosition(position:)` from one written with `zoom: 0` anyway — zoom defaults to 0, so by the time a camera arrives the two are one value. android-sdk never had this; MapViewState.kt hands the camera straight to the controller. js-sdk-core carried the same code and loses it in the same change (MapConductor/js-sdk-core#4), so all three platforms now agree. * Add labelPosition to the default marker icon and pick the marker drawn under the tap (#12) * Release 1.3.2
wf9a5m75
added a commit
that referenced
this pull request
Oct 24, 2026
* Make bearing a clockwise map rotation (#10) bearing を「値を増やすと地図が時計回りに回る」向きに統一し、ネイティブ SDK との変換をコアの CameraBearing に集約する。 * fix: zoom 0 is a zoom, not a missing one (#11) moveCameraTo(cameraPosition:) ran every camera through resolveCameraPosition, which read `zoom == 0 && bearing == 0 && tilt == 0` as "the caller only gave me a position" and replaced the requested camera with the stored one, keeping the position alone. A camera that really does ask for zoom 0 — the whole world — matches that test exactly, so it was the one camera the map would not move to. It shows up as a feature that does nothing rather than as a wrong value: the map stays where it was, so what that invites you to conclude is that zoom 0 is unsupported. Position-only already has a way to be said: the `moveCameraTo(position:)` overload. Inferring the same intent a second time from the *value* costs a legal zoom, and cannot tell `MapCameraPosition(position:)` from one written with `zoom: 0` anyway — zoom defaults to 0, so by the time a camera arrives the two are one value. android-sdk never had this; MapViewState.kt hands the camera straight to the controller. js-sdk-core carried the same code and loses it in the same change (MapConductor/js-sdk-core#4), so all three platforms now agree. * Add labelPosition to the default marker icon and pick the marker drawn under the tap (#12) * Release 1.3.2
wf9a5m75
added a commit
that referenced
this pull request
Oct 24, 2026
…explicit 0 (#17) #11 dropped the all-zero test because it took zoom 0 (the whole world) for "not given". Removing it fixed that and lost the other half: a camera built as MapCameraPosition(position:) reset zoom, bearing and tilt to 0 instead of leaving them where they were. The two cannot be told apart from the value, because zoom defaults to 0. So the camera now records which of zoom / bearing / tilt the caller gave (isZoomSpecified, ...), and moveCameraTo(cameraPosition:) fills only the unset ones from the current camera via resolved(onto:). Each property is resolved on its own, and an explicit 0 is used as given. The properties stay Double and read 0 when unset, so the providers, which only read them, are unchanged. copy() keeps an unset property unset.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
moveCameraTo(cameraPosition:) ran every camera through resolveCameraPosition,
which read
zoom == 0 && bearing == 0 && tilt == 0as "the caller only gave mea position" and replaced the requested camera with the stored one, keeping the
position alone. A camera that really does ask for zoom 0 — the whole world —
matches that test exactly, so it was the one camera the map would not move to.
It shows up as a feature that does nothing rather than as a wrong value: the
map stays where it was, so what that invites you to conclude is that zoom 0 is
unsupported.
Position-only already has a way to be said: the
moveCameraTo(position:)overload. Inferring the same intent a second time from the value costs a
legal zoom, and cannot tell
MapCameraPosition(position:)from one writtenwith
zoom: 0anyway — zoom defaults to 0, so by the time a camera arrivesthe two are one value.
android-sdk never had this; MapViewState.kt hands the camera straight to the
controller. js-sdk-core carried the same code and loses it in the same change
(MapConductor/js-sdk-core#4), so all three platforms now agree.