Fix geo projections losing their D3 default rotation - #7976
Open
CAOShurong wants to merge 6 commits into
Open
Conversation
Geo.updateProjection unconditionally called projection.rotate([-rotation.lon, -rotation.lat, rotation.roll]), so the default projection.rotation attributes ([0, 0, 0]) discarded the rotation the d3 projection factory ships with. Six projections are affected (albers, bertin1953, gringorten and peirce quincuncial, sinu mollweide, wiechel). Capture the factory rotation when the projection wrapper is created and compose the user rotation on top of it. Projections whose d3 default is the identity are bit-for-bit unchanged; an explicit rotation now rotates relative to the projection's canonical orientation instead of replacing it. Fixes plotly#7949
The composed d3 factory rotation can carry float64 dust depending on platform math (e.g. 96.00000000000001 on linux runners), so exact toEqual/toBe assertions are environment-dependent. Assert each axis with a tight 1e-9 tolerance instead.
Regenerated from the exact CI environment (kaleido 1.2 / plotly 6.6.0, linux render): the three sheets containing the six affected projections change because their default orientation now follows the d3-geo factory rotation instead of forcing [0,0,0]. Verified deterministic across two independent CI runs (byte-identical PNGs); all other mocks unchanged.
The previous commit regenerated baselines in a local Windows kaleido environment; the committed bytes were the local render, not the CI render, so test-baselines still failed. Replace with the artifacts produced by the CI make-baselines jobs themselves (verified sha256- identical to the CI uploads).
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
1 participant
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.
Problem
Geo.updateProjectionsetsprojection.rotate([-rotation.lon, -rotation.lat, rotation.roll])unconditionally. Sinceprojection.rotationdefaults to[0, 0, 0], the rotation the d3 projection factory ships with is discarded for the six projections that carry a non-identity default (albers[96, 0, 0], bertin1953, gringorten and peirce quincuncial[-90, -90, 45], sinu mollweide, wiechel) — #7949.Fix
Capture the factory rotation when the projection wrapper is created (
projection.defaultRotation) and compose the user rotation on top of it:projection.rotation, the six affected projections now keep their canonical orientation (the reported bug);projection.rotationas additional rotation on top of the projection's own orientation, and are what makes both defaults and explicit values consistent without tracking whether each attribute was user-set.Test
Adds a regression spec asserting
alberskeeps[96, 0, 0]at defaults, composes (96 - 10) whenrotation.lon: 10is set, and thatmercatorstays exactly[0, 0, 0].Fixes #7949