$ wget http://tileserver.4umaps.eu/13/4330/2674.png
–2017-06-10 17:11:37-- http://tileserver.4umaps.eu/13/4330/2674.png
Resolving tileserver.4umaps.eu (tileserver.4umaps.eu)… 18.104.22.168
Connecting to tileserver.4umaps.eu (tileserver.4umaps.eu)|22.214.171.124|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 65549 (64K) [image/png]
Saving to: ‘2674.png.1’
2674.png.1 100%[=====================>] 64.01K 27.5KB/s in 2.3s
2017-06-10 17:11:46 (27.5 KB/s) - ‘2674.png.1’ saved [65549/65549]
$ pngcheck -v /tmp/2674.png.1
File: /tmp/2674.png.1 (65549 bytes)
chunk IHDR at offset 0x0000c, length 13
256 x 256 image, 32-bit RGB+alpha, non-interlaced
chunk sRGB at offset 0x00025, length 1
rendering intent = perceptual
chunk gAMA at offset 0x00032, length 4: 0.45455
chunk pHYs at offset 0x00042, length 9: 3779x3779 pixels/meter (96 dpi)
chunk IDAT at offset 0x00057, length 65442
zlib: deflated, 32K window, fast compression
chunk IEND at offset 0x10005, length 0
No errors detected in /tmp/2674.png.1 (6 chunks, 75.0% compression).
PNGcheck, version 2.3.0 of 7 July 2007,
$ md5sum /tmp/2674.png.1
$ shasum /tmp/2674.png.1
In addition,an IDAT truncation would cause a truncated image, even if there was no diagnostic from the browser.
I would suspect either an error in whatever is used to download it, or a truncated version has got stuck in a cache between you and the server.
As has already been pointed out, an error in the map would not have resulted in a structurally invalid PNG, so even if your pngcheck diagnostic were valid, there would be no error in the map to find and fix.
[Edited to show direct download rather than the original browser download, to show that the browser is not repairing the file.]
HTTP/1.1 200 OK
Last-Modified: Thu, 25 May 2017 18:36:30 GMT
Date: Sat, 10 Jun 2017 16:48:00 GMT
[Edited to add HTTP meta data. pngcheck -x run to confirm that the file that matches these headers is good.]