[OSM-dev] Newby question

[Frederik Ramm]

Hi,

> 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 
for Mapnik.

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

Bye
Frederik