Invalid LatLng object (NaN, NaN) when trying to zoom out/in with WMS layer.

[Ricardo-C-Oliveira]

I'm trying to add a WMS layer on top of the base the base tile layer and I'm getting the following error: Uncaught Error: Invalid LatLng object: (NaN, 0)

Here is my resolution set-up based of polarmap.js.

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)); };

My layer also comes as EPSG: 3573, so I'm assuming that the same values used for the ArcticConnect base tile would be valid for my WMS, correct?

Did anyone ever encountered a similar issue when add extra WMS layers?

[openfirmware]

Hello!

Are you using the built-in Leaflet API for the WMS layers? I haven't tested the library with WMS, so I will have to add an example that covers that. It may be necessary for me to create a new WMSTileLayer class for WMS that combines Leaflet's TileLayer.WMS with PolarMap's LAEATileLayer, but I would have to investigate first.

Unfortunately the error Uncaught Error: Invalid LatLng object: (NaN, 0) happens somewhat frequently when using PolarMap.js, even without WMS. I have a feeling it is coming from a weird interaction in Proj4Leaflet, but I'm not sure.

[jenseva]

I am also trying to use a WMS layer and get the same error. in my case, it does seem to be related to proj4leaflet. There is a branch of proj4leaflet that has some new functionality which may help with the issue: https://github.com/kartena/Proj4Leaflet/tree/leaflet-proj-refactor

[ryanjdillon]

Is this data at the edge of the bounds of the PolarMap projection? It sounds like Proj4 map be projecting it to a value outside of the map area. A quick-fix would be to filter data within x min/sec of PolarMap's southern parallel.

P.s. - I just stumbled across this and am guessing, but I have had similar problems in my modeling endeavors.

[ryanjdillon]

Just cam across this (old, closed, but not resolved) issue in the Proj4Leaflet repo
kartena/Proj4Leaflet#80

TL;DR
Using the wrong resolution for tiles will yield this error when zooming.

Update

Looking at the leaflet Arctic example from GFIB, after looking at issue #6, it appears as this issue could be related. Try including the var extent as Matt suggests in #6 and the try statement.

var pixel_ratio = parseInt(window.devicePixelRatio) || 1;

var max_zoom = 16;
var tile_size = 512;

var extent = Math.sqrt(2) * 6371007.2;
var resolutions = Array(max_zoom + 1).fill().map((_, i) => ( extent / tile_size / Math.pow(2, i-1) ));

var crs = new L.Proj.CRS(
	'EPSG:3575',
	'+proj=laea +lat_0=90 +lon_0=10 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs',
	{
		origin: [-extent, extent],
		projectedBounds: L.bounds(L.point(-extent, extent), L.point(extent, -extent)),
		resolutions: resolutions
	}
);

var map = L.map('map', {
	crs: crs,
}).setView([51.6, -2.8], 6);

// This gets round a bug, when Leaflet tries to find the coordinates for pixels outside the projection (e.g. top left corner of top left tile).
// https://github.com/kartena/Proj4Leaflet/issues/82
// Restricting the view is probably necessary to avoid the problem properly.  Or fixing the problem properly.
try {
	//L.tileLayer('../512.png?{z} {x} {y}', {
	L.tileLayer('https://tile.gbif.org/3575/omt/{z}/{x}/{y}@{r}x.png?style=gbif-classic'.replace('{r}', pixel_ratio), {
		tileSize: tile_size,
		minZoom: 1,
		maxZoom: 16
	}).addTo(map);

  L.tileLayer('https://api.gbif.org/v2/map/occurrence/density/{z}/{x}/{y}@{r}x.png?style=classic.point&srs=EPSG%3A3575'.replace('{r}', pixel_ratio), {
	  tileSize: tile_size,
    minZoom: 1,
    maxZoom: 16
  }).addTo(map);
}
catch (err) {
	console.error(err);
}