Closed pmikla14 closed 7 years ago
I'm also heaving the exactly same problem.
I found that even when the WMS layer comes in the same projection set-up by Proj4Leaflet the error occurs.
Sorry for not answering this issue...
One thing is you should not use both scales and resolution, using just resolution could do the trick. Are you alse using both scales and resolution @Ricardo-C-Oliveira
There is a working example here using leaflet 1.0.0-rc.3 https://github.com/kartena/Proj4Leaflet/blob/leaflet-proj-refactor/examples/local-projections/europe/script_austria.js
@semone I'm only using resolution which is defined by:
var ORIGINS = { '3573': [-20037508, 20037508] };
`var maxResolution = (tileDetails.origin[1] - tileDetails.origin[0]) / 256;
var resolutions = [];
for (var i = tileDetails.zoom.min; i <= tileDetails.zoom.max; i++) {
resolutions.push(maxResolution / Math.pow(2, i));
};
`
The projection I'm attempting to use is EPSG:3573
Everything works fine with the base tile layer: http://webmap.arcticconnect.org/tiles.html The problem starts when I try to add a WMS layer on top of it, even when WMS is being served in the same projection.
I'm actually able to replicate this using base tiles as well. The issue comes up any time Leaflet tries to call L.CRS.pointToLatLng
on a screen point that the CRS
instance can't unproject (probably outside of the extent). This is coming up most often with WMS layers because Leaflet is trying to unproject the (0,0) tile point, and if you're zoomed out enough that origin is outside of the projection's extent, but it can also come up if you try to scrollwheel zoom in or out in the right place or even just pan far enough outside of a projection's extent.
I think for our purposes we may try altering the way that Leaflet makes its WMS tile requests to see if we can restrict those requests to only valid points. I'll let you know what I find on that front.
Wrapping this line in a basic try/catch did the the trick, but we'd probably want to do something a bit more elegant there:
try {
this._addTile(queue[i], fragment);
} catch () {}
I'm a bit confused by this issue. Which version of Leaflet are you using, and which version of Proj4Leaflet?
Also, providing an actual running example, like on http://playground-leaflet.rhcloud.com, would help a lot.
I'll put together an example of this, but you can also see the error in action in one of the PolarMap demos here that uses proj4leaflet. Choose the "Use ArcticConnect" option at the right, zoom all the way out and then try to scroll zoom with the mouse located near one of the viewport edges and you'll see the same error.
@perliedman You can find an example of the WMS layer issue in this JSFiddle. The zoom level set in this example (zoom: 4
) causes the error, but if you change this to zoom: 5
you'll see that it fetches the tiles correctly. The error traceback goes back to L.TileLayer.prototype._addTilesFromCenterOut
. In this version of the JSFiddle you'll see a crude patch to that method that eliminates the original error.
@jduckworth Digging through the stacktrace, it seems the projection in the fiddle isn't well defined for the point (0, 0)
- doing inverse returns the lat/lng (0, NaN)
.
I note that (0,0)
is well outside the projected bounds if you look at http://epsg.io/3572, so the problem is probably trying to use the projection outside its bounds. I think it should work if you try to limit the map's bounds to avoid it loading these tiles.
Actually, it looks like using the maxBounds
option in these polar projections doesn't have the desired effect. I'll open a separate issue on that. See #122.
After looking into this some more, the issue does not seem to be that the (0,0)
point is outside of the projected bounds. When I implemented my hacky try-catch
above it correctly rendered all of the tiles except the one with its north-west corner on the projection origin. As it turns out, it was basically trying to unproject that origin, which corresponds to {lat: 90, lon: 180}
.
The point of failure seems to be here, where Leaflet first unprojects this origin point to the a LatLng
object and then reprojects to get the coordinates that are actually used in the tile request.
This fix gets the projected coordinates for the tile request directly from the pixel point rather than going through a LatLng
object.
@perliedman We ended up working out a fix for this issue and #122 in our application that involved reopening some core Leaflet classes and changing the way that some calculations are done. There were a number of other places in the core Leaflet code where points are first converted to LatLng
before being converted into, say EPSG:3857
, even when such a conversion is not strictly necessary.
It sounds like Leaflet is making an effort to include better support for non-standard projections. I'd be happy to put in a pull request with a more thorough solution to this problem in the Leaflet library, but I also don't want to duplicate effort if others are already working on solving this issue. Do you know if there is already development happening on this?
@duckontheweb pretty sure there's no such work going on, so we'd be very happy to see your suggestions!
I tried to include a specific open-data map from the Austrian government with the coordinate system EPSG 31258. The map shows up, but only in one zoom level (17). When i try to switch the zoom level I get an Invalid LatLng object (NaN, NaN) error. Dragging around works fine.
Could anybody tell me if there is an error in my code?
Thanks!