Default projection to lv95 #470
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
as it was used only in the footer for the mouse pointer tracker, it can be stored directly there
preparation work to have the projection set in the store
splitting of the file coordinateUtils.js in smaller chunks, all in a new utils/coordinates folder All coordinate format related information have been moved from the class CoordinateSystem to a new CoordinateFormat class, this way we can handle UTM and MGRS representation without polluting available coordinate system with them (as they are a representation of WGS84, and not really a coordinate system we could use with our mapping framework)
The profile API can now split coordinates outside of LV95 with any coordinate inputs (it needs to know in which coordinate system these coordinates are expressed).
removing the provide/inject approach, and use instead a slot I had to remove the use of the "out of the box" OpenLayers Overlay, as it was creating many width issue with the content of the popover. Instead it now follows the same logic as what is done on the Cesium side. Also fixing some issue that I detected in the CoordinateSystemBounds isInBounds and splitIfOutOfBounds, as it was not taking the border of the bound as in bounds renaming util function reprojectUnknownSrsCoordsToWebMercator into reprojectUnknownSrsCoordsToWGS84 as it was misguiding to name the output WebMercator (usually we use this name for coordinates expressed in meters instead of degrees)
as it is an array of coordinate, we have to map it to reproject, not reproject the array itself this commit also makes the export CSV projection agnostic
Changing how marker-text determines the ending coordinate of the drag and drop of icon, and text placement so that we do not use magic number anymore. Exposing the OL map instance to Cypress to achieve that. Removing start of URLs from the 3D layers test, as it was sometimes clashing with stagging (mismatch of base URLs)
wherever component were not linked to the store yet. For others (those who already use the store) this will come later when the projection is in the store add a default projection in the config that is then used as the default in all relevant components
As some data from backends are processed (re-projected), we need to reproject any data of the sort at each projection change. Plus the map view in OpenLayers must change, as we do not have the same constraints when we use Mercator as the one with LV95. In LV95 we want to constraint the resolutions to match exactly the ones from all our printable production (NationalMap 1:25'000, 1:50'000 and onward)
depending on the projection system we want to round, less magic numbers
The `<coordinate>` element in KML must be in WGS84 based on the specification. During export the coordinates where re-projected from WebMercator even if another projection was used.
…lement in WGS84 The editableFeature that is stored in the KML files doesn't have anymore the coordinates to avoid projection issues. KML files have always coordinate in WGS84 as specified in its official spec. The editableFeature then has its coordinates in the corresponding application projection. It gets its coordinates from the OL Feature geometries. We use the OL KML parser properly in order to do the coordinates translation from WGS84 into the application projection. Due to these changes it appears that now the geometry parsed by the KML parser have the 'xyz' layout while they had previously the 'xy' layout.
When editing a drawing component (marker text or adding a text element) the viewer crash because the feature watch deep was fired when no layer was set. To avoid we only watch on the geometry and make sure that we do have a geometry.
The projection is already set as computed property from the store in the `drawingInteractionMixin`
We could not move the drawing component due to the arrow of the tooltip that overtook the pointer event instead of passing them to open layer.
and the fact that the center of the view is now back to a specific value, and not the center of the LV95 (or default projection) bounds
and also reprojecting LV95 coordinate if they come from a legacy URL, and the app is supposed to work in WebMercator
There no need for a default zoom value as we are already setting it above anyway Reprojecting lat/lon or N/E,x/y only once after parsing them
they now "talk" only in LV95 with the backend, and re-project as needed the output to the required mapping projection
removing default projection value for height API (could lead to confusion) clarifying the role of the output projection in the search API fixing the generation of the shortLink in the location popup, as we've now moved to expressed the position of the map as a "center" URL param instead of lat/lon couple
When selecting a drawing feature outside the drawing mode (to see the details and descriptions) and then entering the drawing mode, the feature stayed selected but was not initialized properly to allow edition. This means that we could edit it, but the changes were not reported to openlayer and thus not saved on the kml, which means that the changes were lost when exiting the drawing mode. A simple solution to this issue, is to simply deselect everything on entering the drawing mode. This also make sense in user point of view.
Based on review comments.
…-e2e BGDIINF_SB-2890: Fixed goelocation e2e tests
only shown when we are not on a productive host
BGDIINF_SB-2890 : move projection toggle into a debug toolbar
when using non-fixed projection (hard-coded) in the parsing, but dynamically adapt to the one from the args
but base it on the default projection's center, and some re-projection pre-work
So there's no need to remind ourselves to set it up if we want to use our projection constants in tests (and use them with proj4)
…-search BGDIINF_SB-2890 : fix coordinate search
Update develop-lv95
The WGS84 output cannot be rounded as it is formatted by openlayer with a fixed size of digit to 5.
…on-e2e BGDIINF_SB-2890: Fixed mouse position tests
The legacy parameter coordinates were not correctly reprojected. This was due to the fact that the reprojection happened in a loop several times instead of once. This has been solved by reorganizing a bit the code. Also corrected a test case that did not make sense with the new lv95 default projection. Now all legacyParamImport.cy.js test are passing.
…m-e2e BGDIINF_SB-2890: Fixed legacy parameters coordinates
…x on mobile This was making the drawing e2e tests failing.
…re-e2e BGDIINF_SB-2890: Moved the debug tool bar to avoid overlapping infobox on mobile
URL param parsing : processing projection before position, so that when we (cold) start the app with &3d=true, it correctly transition from the default center to the same one but re-projected in Mercator Moving all "position" related reprojection from the store plugin to the store file (no need to separate it, as it is the responsibility of the store file to handle its own stuff) In Cypress commands.js : only hard coding the center to the old value when 3D flag is not present (other a center expressed in LV95 is added to the URL while it should function in Mercator when in 3D)
Do not set the same projection (and do reproject processes) renaming of the plugin that now only reproject selected features
Do not request feature to the backend when we change projection, but only reproject on the fly Feature API file now only requests feature detail in LV95, and transform/reproject the result into the wanted projection (had some issue with Mercator support in some instances) Move the debug toolbar a bit down, so that it doesn't cover the middle of the map div. It was failing some tests because of that (Cypress thought something was covering a click on the center of the map) now that we reproject everything on the fly, instead of waiting for a backend response
…_test BGDIINF_SB-2890: fix infobox test
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.
Relates to ticket BGDIINF_SB-2890
TODO:
developbranch we don't have the issue but their we use the WMTS service with LV95 and do a reproject on the viewer side to Mercator, while now ondevelop-lv95we use directly the WMTS service with Mercator ! So it might be an issue with our WMTS backend. See ticket BGDIINF_SB-3164zoomToExtentis working properly after BGDIINF_SB-3084 : GUI for import results #476 is merged ondevelopand we've rebased this branchzoomToExtentis still not working no changes betweendevelopanddevelop-lv95. We need to fix it later on within BGDIINF_SB-3153TODO after merge on develop
Test link