fix identification of native_srs for wms services #2136
Merged
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.
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
dictProblem:
_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 availableSolution:
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
.