fix: guard extent reprojection against NaN for globally-advertised WM… - #1590
Open
fguirrugo wants to merge 1 commit into
Open
fix: guard extent reprojection against NaN for globally-advertised WM…#1590fguirrugo wants to merge 1 commit into
fguirrugo wants to merge 1 commit into
Conversation
…S/WMTS layers WMS EX_GeographicBoundingBox and WMTS WGS84BoundingBox commonly advertise -180,-90,180,90 to mean "covers the whole world" (a common, spec-legal pattern used by many global raster/basemap servers). Reprojecting a latitude of +/-90 into Web Mercator is mathematically undefined, and proj4 silently returns NaN instead of throwing. This NaN extent then flows unguarded into addLayer -> zoomToExtent (position.store.js), which commits NaN center/zoom directly to the store, bypassing the bounds validation that the normal setCenter action performs. The result is a broken map viewport (frozen/blank map) any time a user imports an external WMS/WMTS layer covering the whole globe with "zoom to extent" enabled - a common, ordinary user action. Add a small reprojectExtent() helper in both capabilities parsers that validates the reprojected coordinates are finite before using them, falling back to null (already handled gracefully via the existing "no extent found" log/parent-lookup logic) instead of silently propagating NaN. Also harden zoomToExtent() in position.store.js as a second, independent guard against non-finite computed centers. Covered by two new unit tests reproducing the global bounding box case for both parsers.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
…S/WMTS layers
WMS EX_GeographicBoundingBox and WMTS WGS84BoundingBox commonly advertise -180,-90,180,90 to mean "covers the whole world" (a common, spec-legal pattern used by many global raster/basemap servers). Reprojecting a latitude of +/-90 into Web Mercator is mathematically undefined, and proj4 silently returns NaN instead of throwing.
This NaN extent then flows unguarded into addLayer -> zoomToExtent (position.store.js), which commits NaN center/zoom directly to the store, bypassing the bounds validation that the normal setCenter action performs. The result is a broken map viewport (frozen/blank map) any time a user imports an external WMS/WMTS layer covering the whole globe with "zoom to extent" enabled - a common, ordinary user action.
Add a small reprojectExtent() helper in both capabilities parsers that validates the reprojected coordinates are finite before using them, falling back to null (already handled gracefully via the existing "no extent found" log/parent-lookup logic) instead of silently propagating NaN. Also harden zoomToExtent() in position.store.js as a second, independent guard against non-finite computed centers.
Covered by two new unit tests reproducing the global bounding box case for both parsers.