[OSM-dev] Re: New renderer... move to Ruby/rmagick?

[Mikel Maron]

Hi Nick,


> After that I would like to attempt to tackle two of the issues with the 
> renderer at higher zoom levels -- round caps, and antialiasing, neither of 
> which are supported by PHP/GD.
> 
> I am considering switching to Ruby/rmagick for the following reasons:

There is an ImageMagick extension for PHP if that's an easier intermediate step.

> - it appears to support both these features
> - the speed concerns I had about Ruby for the contours would not be 
> applicable if the contour generation code went into its own WMS layer. 
> i.e. the contour drawing code could remain in PHP.

Contours in its own WMS layer is cool. I (or Steve) can help configure mapserver on tile for each layer.

> - better integration with existing Ruby database code
> - enables me to learn a new language properly... :-)
> 
> I guess "suck it and see" is the key thing but does moving to Ruby/rmagick 
> raise any alarm bells? I'd guess at the moment the SQL is the rate 
> determining step rather than the scripting language.

I don't think we know. My tests earlier this year were not comprehensive, but seemed to show a big performance hit for Ruby doing
iterative calculations; Perl seemed to perform much better, and C would be even better. Neutral benchmarks back this up..

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=ruby

We should set up some tile drawing tests without the database dependency, to see clearly the efficiency here.

Also, Ruby can be extended with C code quite cleanly. This would allow us to keep the SQL queries in one place in the ruby code, while
executing the intensive drawing routines in C.

-Mikel