[Tilesathome] Osmarender Perl implementation

[Frederik Ramm]

Hi,

    I have almost finished my long-time pet project, a full Osmarender
re-implementation in Perl. It is stylishly called or/p (for, who would
have guessed, Osmarender in Perl).

I'd like to ask those of you who are interested to play with it and
see whether it works for you. It is designed to be a 100% compatible
drop-in replacement, i.e. uses the same input files, same rule files,
and generates the same output. You'll find it all in SVN under

/applications/rendering/orp/

The initial goal is to be as compatible with Osmarender/XSLT as
possible. That means I have deliberately *not* built in some
optimisations that came to my mind, for the time being.

The Perl implementation as it is now requires between 25% and 50% of
the time required by the XSLT implementation, and uses about 20% of
memory. I expect these numbers to grow a bit once we have
implemented the last bells and whistles.

My main reason for doing or/p is that I think it will attract more
development activity than Osmarender/XSLT did. I have a lot of respect
for the playful way in which people manage to get XSLT to do what it
was never meant to do (e.g. add 800+ lines of code to do trigonometric
calculations using recursive templates!), and the results may have
some things going for them but they tend to be very difficult to
modify and understand by others - and what good is open source if
nobody understands the source?

So my hope is that once people start to use or/p, it will be rather
easy for them to add improvements and, above all, optimisations that
will create leaner SVG output that in turn requires less time and
memory on the part of the SVG renderer.

I also believe that or/p will provide a basis for combining the various
preprocessing and postprocessing steps (e.g. close-areas, merging of
slices of OSM data into one file, bezier curve hinting) into one
smooth application.

With or/p, it will also be trivial use a proper Mercator projection
and/or switch to any other projection (outside tiles at home of course -
tiles at home is tied to Mercator) by using the proj.4 library.

In the first lines of orp.pl you will find a list of things that don't
currently work; everything else should work. I'm sure though if you
play with it that you'll uncover some bugs or places where I simply
misread the original XSLT and put in the wrong logic... I made a
modified version of tilesGen.pl to run with orp and compared the
output with Osmarender/XSLT - it looked identical to the point where
you could intermix old and new tiles on a slippy map and see no
differences (except the font size bug I still need to find). Sometimes
a road might be a pixel off or so because or/p uses built-in
trigonometric functions where Osmarender/XSLT uses the first elements
of a Taylor series for approximation.

If you want to work on or/p, by all means do. I'm sure not all design
choices I have made are optimal, and the whole could perhaps use a
better modularisation than I have provided. I have tried not to use
any "magic" stuff in there and to document everything so that it
should be easy to understand and modify.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'