[OSM-dev] Newby question
frederik at remote.org
Mon May 12 15:44:16 BST 2008
> I'm interested in the relative runtime of the
> sub-components of the Osmarender-based tile generation process. Specifically
> the relative time for running the Osmarender code itself (the XSLT+Perl)
It is "XSLT *or* Perl"; Osmarender is available in both flavours.
> versus rendering the resultant svg as a tile? I am presuming the former is a
> small proportion of the total runtime whilst the svg rendering dominates?
In theory this depends on the complexity of the rendering rules. An
extreme example would have very complex rules that in the end were
mostly there to filter out the small amount of interesting stuff and
draw that - resulting in a long processing time on the Osmarender side
and a very showr processing time on the SVG side (because so little has
been drawn). In practice, and for typical map data, the time spent in
the SVG renderer far outweighs the Osmarender time (the higher the zoom
level, the more time spent in SVG).
But as Shaun has already said, if you want fast results and don't
require any of Osmarender's special features or capabilities, just go
> If not, I was wondering if there's any interest in developing a version of
> the code in a compiled language for efficiency reasons?
I doubt there's much to gain. The Perl code already uses a native C
backend storage module for the bulk of the work (that is selecting or
de-selecting items for rendering). Doing the rest in C as well might
gain you another factor of 2 or so. The most promising path to improved
Osmarender performance is probably better filtering - make sure that the
SVG contains only the bare minimum required to render the image and not
tons of extra stuff.
More information about the dev