Author: tom[at]compton.nu
[Added to the original trac issue at 12.01pm, Thursday, 10th April 2008]

It would be a lot easier to investigate if you had given links to the slippy map instead of the MapOf service where I can't poke at the tile URLs with FireBug... For the record the corresponding location on the slippymap is:

http://www.openstreetmap.org/?lat=51.0858&lon=14.1401&zoom=14&layers=0BFT

and the problem tile appears to be:

http://tah.openstreetmap.org/Tiles/tile.php/14/8835/5478.png

the only problem is that it seems to be fine for me - the server is returning a grey tile that matches the adjacent tiles.

Author: stoecker
[Added to the original trac issue at 12.46pm, Thursday, 10th April 2008]

Your right. The problem does not appear in http://www.openstreetmap.org/?lat=51.0858&lon=14.1401&zoom=14&layers=0BFT

But it appears in http://tah.openstreetmap.org/MapOf/
Giving you the link to the slippy map wouldn't have helped, as there the problem does not exist.

Seems you searched at the wrong place. Maybe it's a bug in MapOf scripting. Don't know. But I know there are white patches in the maps, which you can verify yourself, when loading the links I gave.

Author: tom[at]compton.nu
[Added to the original trac issue at 1.06pm, Thursday, 10th April 2008]

I just find it very hard to believe that this is MapOf specific - all that does is fetch the tiles and stitch them together, and there doesn't seem to be anything special about that tile.

Author: stoecker
[Added to the original trac issue at 1.10pm, Thursday, 10th April 2008]

Looking at the mapof script:

60 	      if(file_exists($Filename)){
61 	        $ToX = (floor($Width/2) - $XA + $xi * $Tilesize);
62 	        $ToY = (floor($Height/2) - $YA + $yi * $Tilesize);
63 	 
64 	        if($ToX > -$Tilesize && $ToX < $Width
65 	          && $ToY > -$Tilesize && $ToY < $Height){
66 	          $Part = imagecreatefrompng($Filename);
67 	          imagecopy($Image, $Part,
68 	            $ToX,
69 	            $ToY,
70 	            0, 0,
71 	            $Tilesize, $Tilesize);
72 	          }
73 	        }[

Probably the problem here is, that in case file does not exists, the area must be cleared.

Or in line 46

46 	  imagefilledrectangle($Image, 0,0,$Width, $Height, $BG);

set the correct background color and save the work for non-existing tiles.

osmarender for sure is the wrong component, but I do not know better, that's why I choose admin.

Author: stoecker
[Added to the original trac issue at 1.23pm, Thursday, 10th April 2008]

Line 45 I meant

45 	  $BG = imagecolorallocate($Image, 255, 255, 255);

When you change that to 248,248,248 the problem should be solved.

BTW: Could the width/height limit be increased from 2000 to 3500? That would be 300dpi for A4 paper.

Author: tom[at]compton.nu
[Added to the original trac issue at 1.43pm, Thursday, 10th April 2008]

The point is that the file does exist - I posted the URL for it!

Author: stoecker
[Added to the original trac issue at 1.48pm, Thursday, 10th April 2008]

You're really sure?

As I see the scripts run on the same server and mapof directly accesses the files.

Are empty tiles really stored, or is there a list containing empty tiles and send default tile for these? In the second case they are not physical reachable and the mapof test will fail, whereas the server delivers a default tile. Thought this is only speculation, as I had no deep look into the server working mechanisms. But it is the way I would design it :-)

Author: tomhughes
[Added to the original trac issue at 12.08pm, Sunday, 13th April 2008]

(In [7351]) Change background colour to match T@H tiles. Closes #828.