Talk:Osmarender bug

Really a bug?

First of all, this is not an osmarender bug but a bug in the way omsarender is employed by tiles@home. Osmarender itself knows nothing about tiles. But having looked at the tiles@home source, I am not sure whether there is a bug at all...

As far as I understand:

• Osmarender itself uses an approximation of the Mercator projection:

<xsl:variable xmlns:xsl="http://www.w3.org/1999/XSL/Transform" name="middleLatitude" select="($topRightLatitude + $bottomLeftLatitude) div 2.0"/>
<xsl:variable xmlns:xsl="http://www.w3.org/1999/XSL/Transform" name="latr" select="$middleLatitude * 3.1415926 div 180.0"/>
<xsl:variable xmlns:xsl="http://www.w3.org/1999/XSL/Transform" name="coslat" select="1 - ($latr * $latr) div 2 + ($latr * $latr * $latr * $latr) div 24"/>
<xsl:variable xmlns:xsl="http://www.w3.org/1999/XSL/Transform" name="projection" select="1 div $coslat"/>

It is only an approximation because only the first two elements of the cosine Taylor series are used (trigonometric functions are not available in XSLT).

• When rendering a tileset, the corners of the tile are projected accurately. So the level-12 tile is always correct, apart from the minor flaws introducted by Osmarender's approximation.

• Tiles@home is believed to have a bug where it splits the level-12 area exactly in the middle to produce the level-13 tiles (and so on down to level-17). But the current source of tilesGen.pl reads

# Sub-tiles
my $MercY2 = ProjectF($N);
my $MercY1 = ProjectF($S);
my $MercYC = 0.5 * ($MercY1 + $MercY2);
my $LatC = ProjectMercToLat($MercYC);

(with $N and $S being the maximum and minimum latitude). It looks correct to me - it computes a "pixel" value for the centreline, then applies an inverse Mercator projection to get the centreline as a latitude value.

I don't currently see what is wrong here... maybe someone else does? --Frederik Ramm 18:31, 14 February 2007 (UTC)

Ah, finally got it. Because you cannot have functions in XSLT, only the middle of the area to be rendered is actually projected by Osmarender, and the rest is done by an affine transformation (stretching to fit). So I was wrong in stating that level-12 tiles are always correct, and it isn't about the tiling at all, but really an Osmarender internal process. Sorry for the confusion. --Frederik Ramm 09:03, 15 February 2007 (UTC)

Don't forget: no matter what aspect-ratio the osmarender output has, this will be made into a square when it's rendered into a tile. So any osmarender projection code applied equally to the entire tile will have no effect on the output. Ojw 13:33, 15 February 2007 (UTC)