[Tilesathome] Osmarender Bugfix

[80n]

Brent
The issue you describe is a problem related to the generation of captions on
areas as you correctly infer.

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 at 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.


80n

On 10/22/07, Brent Easton <b.easton at exemail.com.au> wrote:
>
> 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:
>
>       <text k="name" class="caption-casing generic-caption-casing"
> text-anchor="middle" startOffset="50%" x="NaN" y="NaN">Werri Beach</text>
>       <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.
>
> Regards,
> Brent.
>
> *********** REPLY SEPARATOR  ***********
>
> On 22/10/2007 at 1:41 AM Frederik Ramm  wrote:
>
> >Hi,
> >
> >   I have tried to fix the Osmarender bug that dropped all street
> >names where the direction of the way is different from the desired
> >text direction (the one where it generated references to a reverse
> >path which it subsequently forgot to generate).
> >
> >I don't really understand what it all does, I just did the
> >programmer's equivalent of taking a hammer to it and see if it works.
> >And work it did, for my example files at least. But if anyone thinks
> >the situation has worsened, just revert!
> >
> >Bye
> >Frederik
> >
> >--
> >Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'
> >
> >
> >_______________________________________________
> >Tilesathome mailing list
> >Tilesathome at openstreetmap.org
> >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.488 / Virus Database: 269.15.5/1084 - Release Date:
> 21/10/2007 3:09 PM
>
>
> ____________________________________________________________
> Brent Easton
> Analyst/Programmer
> University of Western Sydney
> Email: b.easton at uws.edu.au
>
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071022/61e03308/attachment.html>