PB-97 : implement zoom to extent in 3D #599
Merged
Conversation
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
Passing run #232 ↗︎
Details:
Review all test suite changes for PR #599 ↗︎ |
|||||||||||||||
ltshb
reviewed
Jan 11, 2024
pakb
force-pushed
the
bug_PB-97_zoom_to_extent_in_3d
branch
from
9ed86ec to
8a7421c
Compare
there could otherwise be some race conditions where a shorthanded is used before its definition, resulting in an uncaught error in the console (and an app crash if starting the app with Cesium)
The sync camera plugin was monodirectional, and wasn't reacting to changes made to the center or zoom (which is what is triggered when we do a zoomToExtent) As this plugin is listening to mutation it triggers itself, I had to defend against infinite calls with some flagging inside the sync module. I decided to revert the camera rotation on all axis when zooming to an extent, as I found it too difficult to calculate the equivalent without being straight into the Cesium viewer, and having access to function of the Cesium camera.
making sure the sync camera plugins only reacts to setCenter and setZoom when 3D is active, otherwise it will write the camera also in 2D. moving up the camera store param parsing, as it is now not required to have it after the 3D param parsing. And as the camera sync plunig now wants to have the 3D flag set to true to react to a setCenter, it's better dealing with both center and camera before the 3D flag is set up (less chances of race condition at app startup in the sync camera plugin this way)
pakb
force-pushed
the
bug_PB-97_zoom_to_extent_in_3d
branch
from
8a7421c to
367c3fd
Compare
So that we can differentiate them in the 2D/3D sync plugin (and in the console debug logs) without the need for the 2D/3D sync plugin to declare many flags, rendering the code difficult to understand
pakb
force-pushed
the
bug_PB-97_zoom_to_extent_in_3d
branch
from
367c3fd to
7e90116
Compare
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.
Small changes before the main commit : only export logging utils when shorthanded are defined, there could otherwise be some race conditions where a shorthanded is used before its definition, resulting in an uncaught error in the console (and an app crash if starting the app with Cesium)
The sync camera plugin was monodirectional, and wasn't reacting to changes made to the center or zoom (which is what is triggered when we do a zoomToExtent)
As this plugin is listening to mutation it triggers itself, I had to defend against infinite calls with some flagging inside the sync module.
I decided to revert the camera rotation on all axis when zooming to an extent, as I found it too difficult to calculate the equivalent without being straight into the Cesium viewer, and having access to function of the Cesium camera.
Test link