-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Release v1.22.0 - #minor #891
Merged
Conversation
This file contains 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
While testing geolocation it often results to really poor accuracy, sometimes up to several kilometers !
External layers (kml, gpx, wmts, wms) at the bottom of the stack where replaced by default topic layers during startup if the layers came from a legacy link. This issue was due to a performance improvement that avoid to recreated layer object if it was already present, but this performance improvement did not check if the layer at index was the correct ID.
Each layer might have a default opacity from the layer config therefore only clone current layer config for external layers and kml (kml created by the web-mapviewer are not considered as external).
PB-574: Fix layers parameter issue at startup
Issue: The transparency slider did not change the opacity in real time when users were moving the slider, only applying the changes when it was released Fix: When clicking on the slider, it sets an interval which updates the opacity as long as we're handling the slider. This interval is set to 100ms, which allows to see the changes happen often enough to work, without burdening the backend with too much commits. We also reduce the number of commits by never committing the same value as the one stored.
linting and removing dev logs update in log
forcing this resulted in KMLs being misrepresented, with colors not matching what was in the KML's data
the style of KML loaded from the import file tool is the default style OpenLayers applies to KMLs, and not the one we have been adding in our DrawingModule. Tests here for print were made on the assumption that we are dealing with KMLs coming out of our DrawingModule, hence this change
…tyle PB-562 : do not force drawing module's style onto external KMLs
using stock Cesium classes to load KMLs instead of relying on ol-cesium bridge transforming the Cesium KML component into a composition API component in the process (exit mixins) Adding a couple tweaks depending on the geometry type : - disabling depth with terrain testing with labels (always visible) and adding more outline - clamping icons (billboard) to the terrain, so that they aren't clipped by it - lowering the default alpah/transparency of polyline/polygon material, to ease the visualization of underlying buildings and other features - forcing clamping to ground for polyline, meaning a measure line will follow the terrain, always
PB-591 : 3D KML improvements
Removing 2D position URL params when 3D is active to diminish issues when we load the app directly in 3D. When zoom and/or position are present, the 3D viewer would react to changes in these values. This was creating some race condition issue at startup when a camera position was also described in the URL. Camera initialization has also been separated from the logic to move the camera after init, so that we have a clearer logical decision (with logging)
PB-548 : fix camera position present in URL at startup issue
…ted to center Parameters X/Y and E/N legacy parameter were not translated to the center paramter which resulted to have center on the bottom left corner of LV95 projection.
Legacy parameter X/Y can be given either in LV95 or LV03 projection
Passing run #2437 ↗︎
Details:
Review all test suite changes for PR #891 ↗︎ |
PB517, PB-588: Fixed legacy X/Y parameter in LV03 and LV95
Using proj4 isn't accurate enough on a geodesic point of view, as the conversion isn't linear. There's a backend service that does the computation in a proper manner, so that's what is being used here when showing a LV03 value in the location popup. Tracking the mouse position while moving the cursor can still be done with a simple matrix transform, it's "good enough"
…lv03 PB-583 : use backend service to get LV03 <> LV95 conversion right
pakb
approved these changes
Jun 10, 2024
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.
Test link