Brent<br>The issue you describe is a problem related to the generation of captions on areas as you correctly infer.<br><br>The reason it is trying to render something that is outside the tile boundary is because long captions can extend beyond the size of the area they label.  To be safe, 

tiles@home renders each tile with some margin each side of the tile.  This is then cropped during image generation.  Without this a lot of names would appear truncated at tile boundaries.<br><br><br>80n<br><br><div><span class="gmail_quote">

On 10/22/07, <b class="gmail_sendername">Brent Easton</b> <<a href="mailto:b.easton@exemail.com.au">b.easton@exemail.com.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Frederik, Thanks, that has fixed many of the problems in the generated SVG.  There is another issue that was raised a while back that I can reproduce on Tile  3763 2469, zoom level 17. The generated SVG contains elements with invalid co-ordinates:

<br><br>      <text k="name" class="caption-casing generic-caption-casing" text-anchor="middle" startOffset="50%" x="NaN" y="NaN">Werri Beach</text><br>

<text k="name" class="caption-core generic-caption-core" text-anchor="middle" startOffset="50%" x="NaN" y="NaN">Werri Beach</text> Werri Beach is an Area feature with the tags natural=beach, name=Werri Beach.

The interesting thing is that Werri Beach is not actually on tile 3763 2469, but is completely contained on the adjacent tile 3764 2469, but close to the edge. Both the beach and it's caption are being added the level 17 SVG even though they are outside the defined drawing box.

Either areas such as these need to excluded from the generated SVG, or the off-tile co-ordinates need to be calculated correctly. This is not a high priority as Inkscape will happily ignore these and the non-display of items not on a tile is not really a problem, but it does need to be cleaned up for Batik testing. It can wait for Etienne.

<br><br>Regards,<br>Brent.<br><br>*********** REPLY SEPARATOR  ***********<br><br>On 22/10/2007 at 1:41 AM Frederik Ramm  wrote:<br><br>>Hi,<br>><br>>   I have tried to fix the Osmarender bug that dropped all street

<br>>names where the direction of the way is different from the desired<br>>text direction (the one where it generated references to a reverse<br>>path which it subsequently forgot to generate).<br>><br>>I don't really understand what it all does, I just did the

<br>>programmer's equivalent of taking a hammer to it and see if it works.<br>>And work it did, for my example files at least. But if anyone thinks<br>>the situation has worsened, just revert!<br>><br>>Bye

<br>>Frederik<br>><br>>--<br>>Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a>  ##  N49°00.09' E008°23.33'<br>><br>><br>>_______________________________________________

<br>>Tilesathome mailing list<br>><a href="mailto:Tilesathome@openstreetmap.org">Tilesathome@openstreetmap.org</a><br>><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome

</a><br>><br>><br>>--<br>>No virus found in this incoming message.<br>>Checked by AVG Free Edition.<br>>Version: 7.5.488 / Virus Database: 269.15.5/1084 - Release Date: 21/10/2007 3:09 PM<br><br><br>____________________________________________________________

<br>Brent Easton<br>Analyst/Programmer<br>University of Western Sydney<br>Email: <a href="mailto:b.easton@uws.edu.au">b.easton@uws.edu.au</a><br><br><br>_______________________________________________<br>Tilesathome mailing list

<br><a href="mailto:Tilesathome@openstreetmap.org">Tilesathome@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome

</a><br></blockquote></div><br>