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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
