Closed scadergit closed 2 years ago
Still wrapping my head around this, but I noticed the transformExtent returned NaN
when it was double-transformed, which would obviously break OL. I injected logs into the computed for components/base-layer.js/extentViewProj that show without the transformExtent (which does work), and with (which doesn't work and has NaN
).
-E is the extent before computed -P are the projections -TE is the extent after computed
Even the TE that is a number seems to be incorrect values.
I think the problem is simply we told Vuelayers to automatically convert data-projection from 4326, but then erroneously fed it 3857 values. In version 11 the computed didn't do this step and "worked," even if it wasn't supposed to.
Going to close this as the new verison functions as designed (unlike V11 that ignored the data projection helper for layer extent).
Hello @scadergit ,
sorry for the late response!
Yes , in VueLayers v0.12 I implemented auto-transform of all coordinates projection in all vue reactive props, fields and etc (including extents, points, geojson representations). Internally by default openlayers ol.View is using EPSG:3857 proj, at the VueLayers level you can use another data-projection
that will be automatically transformed to internal projection.
However if you have tile layer extent not in data-projection
, you can overwrite it's projection via extent-projection
property.
<!-- setup EPSG:4326 as a global data projection for all coordinates at VueLayers level -->
<vl-map data-projection="EPSG:4326">
...
<vl-layer-tile extent-projection="EPSG:3857" :extent="extent_3857">
....
</vl-layer-tile>
</vl-map>
Thanks for the clarification, and for adding the additonal flexibilty.
One of the changes we had to make when bumping from 11 to 12 was this line:
to
because OL would error out computing the extent and not request any tiles.
Here is our simplified setup:
In version 12, vuelayers does calculation on extent within base-layer.vue, whereas version 11 layer.vue seemed to be more pass-through. I'm still stepping through to discover more, but is this an expected change? It would seem this conversion would still be necessary, but does version 12 automatically transform the extent and the double-transform on both ends cause the data sent to OL to be invalid?