Skip to content
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

Fix #10739 Changing correctly resolutions limits when switching map CRS #10746

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

MV88
Copy link
Contributor

@MV88 MV88 commented Jan 13, 2025

Description

We are changing resolutions also in the view because these were not aligned to the layers especially when switching to 4326. ol map view was having a different list causing a misalignment between current resolution and zoom level

Please check if the PR fulfills these requirements

What kind of change does this PR introduce? (check one with "x", remove the others)

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

Issue

What is the current behavior?

Fix #10739

What is the new behavior?

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

  • Yes, and I documented them in migration notes
  • No

Other useful information

@MV88 MV88 added this to the 2025.01.00 milestone Jan 13, 2025
@MV88 MV88 requested a review from dsuren1 January 13, 2025 13:27
@MV88 MV88 self-assigned this Jan 13, 2025
Copy link
Contributor

@dsuren1 dsuren1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MV88
I noticed the following behaviors during testing. Kindly take a look. Thanks!

  • When the visibility limits are set on projection other than the default ones (4326, 3857), switching back to 4326 causes the visibility limits to default to the maximum value for both the min and max fields. This results in the layer being perpetually hidden. This issue occurs exclusively with 4326.

    Tested with 25832, 2154

    "projectionDefs":[{"code":"EPSG:25832","def":"+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs","extent":[229521.4465,0,923521.4465,9329005.182],"worldExtent":[6.0,53.0,15.0,60.0]},{"code":"EPSG:2154","def":"+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs","extent":[-378305.81,6093283.21,1212610.74,7186901.68],"worldExtent":[-9.86,41.15,10.38,51.56]}]
    crs_to_4326.mp4
  • When setting visibility limits on EPSG:4326 and previewing the print map, the layer is hidden in the print preview when the CRS is EPSG:3857. However, it works correctly when the CRS is EPSG:4326 in the print tool

    print-crs-4326.mp4

@MV88
Copy link
Contributor Author

MV88 commented Jan 17, 2025

When the visibility limits are set on projection other than the default ones (4326, 3857), switching back to 4326 causes the visibility limits to default to the maximum value for both the min and max fields. This results in the layer being perpetually hidden. This issue occurs exclusively with 4326.

pushed an update to avoid this scenario

When setting visibility limits on EPSG:4326 and previewing the print map, the layer is hidden in the print preview when the CRS is EPSG:3857. However, it works correctly when the CRS is EPSG:4326 in the print tool

in my case is coherent with what happens when you switch map crs.

@tdipisa
Copy link
Member

tdipisa commented Jan 17, 2025

@dsuren1 I think this is ready then for a new review

@tdipisa tdipisa requested a review from dsuren1 January 17, 2025 16:15
@tdipisa tdipisa added the bug label Jan 17, 2025
Copy link
Contributor

@dsuren1 dsuren1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MV88

When setting visibility limits on EPSG:4326 and previewing the print map, the layer is hidden in the print preview when the CRS is EPSG:3857. However, it works correctly when the CRS is EPSG:4326 in the print tool

The visibility limits on the layer set on main map are not in sync with print preview tool, as the print tool allows user to select a different projection and the values on the layer (min and max resolution) are not modified accordingly, resulting in the layer being filtered out (i.e not visible on the print tool). As we discussed the values needs to converted in a way that the limits are recalculated based on the projection selected in print tool to be viewable on the print as well.
NOTE: This seems to be an existing issue

@MV88
Copy link
Contributor Author

MV88 commented Jan 20, 2025

@MV88

When setting visibility limits on EPSG:4326 and previewing the print map, the layer is hidden in the print preview when the CRS is EPSG:3857. However, it works correctly when the CRS is EPSG:4326 in the print tool

The visibility limits on the layer set on main map are not in sync with print preview tool, as the print tool allows user to select a different projection and the values on the layer (min and max resolution) are not modified accordingly, resulting in the layer being filtered out (i.e not visible on the print tool). As we discussed the values needs to converted in a way that the limits are recalculated based on the projection selected in print tool to be viewable on the print as well. NOTE: This seems to be an existing issue

@tdipisa let's discuss a bit for this sine there are some problems in how resolutions and visibility limits are handled in print preview map:

i did a quick investigation:

  • getPreviewResolution is using scales based on map component not printMap ones that can have a different crs and therefore different resolutions
  • Another issue is that you cannot use visibility limits calculated in the "map" for the printMap since they can have different crs there fore different values of resolutions visibility limits
  • current resolution value is not matching the one in the list i calculate
  • as a result the value of resolution calculated in getPreviewResolution will not fit in the isInsideResolutionsLimits

I guess a dedicated issue must be created since this problem was preexisting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Visibility limits on layer are not consistent when switching CRS
3 participants