Description:
In src/layer/xyz.js, the source's (ol/source/XYZ) projection is always set to the view's projectionCode, regardless of what is specified in the layer or source config:
sourceOptions.projection = viewer.getProjectionCode() || 'EPSG:3857';
This works fine as long as the map uses EPSG:3857 (Web Mercator), which is the most common case. But if the map uses a different projection instead — e.g. EPSG:3006 (SWEREF99 TM), common in Swedish municipal maps — a bug appears: OpenLayers assumes the source and view projections are the same and skips the reprojection that would otherwise happen automatically between projections. The result is that tile coordinates are computed incorrectly, and the layer ends up geographically wrong (e.g. showing imagery of the Netherlands instead of Sweden).
Reproduction:
- Create a map with
"projectionCode": "EPSG:3006".
- Add a layer of type
"XYZ" pointing at a global tile service (e.g. Google Satellite or a generic OSM-style tile server in EPSG:3857).
- Tiles are fetched with incorrect
x/y/z indices because no reprojection occurs, and the layer is misaligned relative to other layers on the same map.
Comparison: The OSM layer type (src/layer/osm.js) is unaffected, since it constructs a plain ol/source/OSM() with no overrides — OpenLayers' own default (EPSG:3857) is used, which differs from the view's EPSG:3006 and therefore correctly triggers automatic reprojection.
Suggested fix:
Respect an explicit projection from the layer/source config before falling back to the view's projection:
sourceOptions.projection = xyzOptions.projection || sourceOptions.projection || viewer.getProjectionCode() || 'EPSG:3857';
This allows specifying e.g. "projection": "EPSG:3857" on the source to correctly consume global XYZ services in a map that otherwise uses a different projection, while leaving behavior unchanged for the common case.
A fix along these lines has been tested in a fork: matself/origo_me@6c07a2c
Description:
In
src/layer/xyz.js, the source's (ol/source/XYZ)projectionis always set to the view'sprojectionCode, regardless of what is specified in the layer or source config:This works fine as long as the map uses EPSG:3857 (Web Mercator), which is the most common case. But if the map uses a different projection instead — e.g. EPSG:3006 (SWEREF99 TM), common in Swedish municipal maps — a bug appears: OpenLayers assumes the source and view projections are the same and skips the reprojection that would otherwise happen automatically between projections. The result is that tile coordinates are computed incorrectly, and the layer ends up geographically wrong (e.g. showing imagery of the Netherlands instead of Sweden).
Reproduction:
"projectionCode": "EPSG:3006"."XYZ"pointing at a global tile service (e.g. Google Satellite or a generic OSM-style tile server in EPSG:3857).x/y/zindices because no reprojection occurs, and the layer is misaligned relative to other layers on the same map.Comparison: The
OSMlayer type (src/layer/osm.js) is unaffected, since it constructs a plainol/source/OSM()with no overrides — OpenLayers' own default (EPSG:3857) is used, which differs from the view'sEPSG:3006and therefore correctly triggers automatic reprojection.Suggested fix:
Respect an explicit
projectionfrom the layer/source config before falling back to the view's projection:This allows specifying e.g.
"projection": "EPSG:3857"on the source to correctly consume global XYZ services in a map that otherwise uses a different projection, while leaving behavior unchanged for the common case.A fix along these lines has been tested in a fork: matself/origo_me@6c07a2c