Skip to content

fix identification of native_srs for wms services #2136

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

Merged
merged 2 commits into from
Feb 21, 2023

Conversation

raphaelquast
Copy link
Contributor

Rationale

While testing several WMS services for EOmaps I realized that there is a flaw in the logic for identifying the "native_srs" of a WMS service:

Current logic:

  • native_srs = axes projection if found in hardcoded _CRS_TO_OGC_SRS dict

Problem:

  • In case the axes projection is found in _CRS_TO_OGC_SRS but the service does not provide the used srs, no search for fallback-srs is attempted and adding the wms will fail even if a fallback srs would have been available

Solution:

  • If the axes projection is valid, only use it if it is actually provided by the service and otherwise continue checking for fallback srs

Implications

WMS services that do not provide the currently used axes projection will now attempt to reproject from available fallback projections even if the axes projection was provided in _CRS_TO_OGC_SRS.

@dopplershift dopplershift merged commit e1786f8 into SciTools:main Feb 21, 2023
@raphaelquast raphaelquast deleted the patch-2 branch February 21, 2023 23:03
@QuLogic QuLogic added this to the 0.21.2 milestone Feb 22, 2023
@greglucas greglucas modified the milestones: 0.21.2, 0.22 Jul 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants